Hmm. That's pretty large. I have to say that I don't feel great about this. Particularly since that rule is hardly a popular one -- nor the most crucial. Perhaps it was too ambitious to imagine changing it and instead it should remain a lint forever (it is, in its own way, a kind of lint anyhow). (cc @aturon)
It's already a pretty big warning anyways. I actually find it quite useful during development that it's just a warning and not an error. It tends to happen every once in a while and the fact that it does not immediately make the build fail I consider a nice feature.
Abandoned projects maybe?
private_in_public was reported as a warning since last autumn, i have hard time imagining how a project maintainer can compile his project and look at these warnings for so long and never silence them with #[allow(private_in_public)].[quote="mitsuhiko, post:4, topic:3930"]
I actually find it quite useful during development that it's just a warning and not an error.
[/quote]
It's still a warning, and it seems like it will proceed being a warning for a long time, it's just deny-by-default now, no downstream projects affected and all that.
As the first crate in the listing (ugh, sorry!), Encoding 0.3 was in the development since early this year (I think) and I had a fix to the warning in the issue list but didn't realize that the 0.2 branch would have the same problem. This is also partly because I haven't set the warning to fail the CI test---but if I had a separate branch for 0.2 I wouldn't be able to see that as new Rust releases do not trigger CI anyway. (So, essentially, same to a pre-1.0 situation.)
I've taken this incident as an opportunity to actually apply the fix to 0.3 branch and also published a quick fix as 0.2.33. Still have to think about the long-term maintenance though...
@petrochenkov we talked about this in the core-team meeting. I think the conclusion was that we don’t feel comfortable with rolling out the private_in_public-deny change this way. We’d prefer to revert that change for the beta (since it’s an easy thing to do) and then we can have a separate discussion (i.e., now…) about precisely how we roll it out (do we need to notify crate authors? submit patches? should we just give up on making this a hard error altogether?)
Would you be up for making that PR?
One thing I don’t know is whether we think we should roll it back just on beta, or also on nightly (@brson, @alexcrichton, your thoughts on that?)
I’d say on both nightly and beta. Reset things to the way they were just in case. But I think with the right preparation it’s reasonable to expect we’ll be confident to deploy to stable nov 10.
The situation when a crate is fixed on GitHub, but the update is not published to crates.io turns out to be pretty common - about half of private-in-public regressions in the list.
@brson in particular fixed stdx but never published stdx-0.0.2
