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)

I think we need to drill more into the process for these warning -> error transitions. For example, here, because this warning was so old, I don't see that we did any crater runs of impact (can that be true? I feel like I do remember some investigation?). However, for https://github.com/rust-lang/rust/pull/34982, we did a crater run, and then I made a point of ensuring that every affected crate was at minimum notified and, if possible, had a pending PR fixing the problem. I believe that for https://github.com/rust-lang/rust/pull/34923 we were similarly diligent.

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.

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)].

mitsuhiko:

I actually find it quite useful during development that it's just a warning and not an error.

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.

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)].

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?)

@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?

OK.denying by default can be discussed again after deciding on RFC 1671.I'll probably start sending PRs to affected crates in the meantime.

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