0.20.1 release?

[yannham]

I feel we have merged quite a bit of useful fixes or improvements since the last version. Nothing groundbreaking, but still quality of life improvements. I'm personally in favor of releasing as much as possible - big leaps between releases just have a higher chance of breaking things. Should we plan for an 0.20.1 release soon? @nikomatsakis @youknowone

[dburgener]

Not a huge deal, but 3b7bde6 lists the deprecation as since = "1.0.0". This 0.20.1 would be the first release to contain that deprecation, so it would be more accurate to mark the "since" value as 0.20.1. That said, it's a pretty minor deal; IIRC the "since" field isn't actually used anywhere, so future dating it is probably not an actual problem.

[Pat-Lafon]

I did that to be in line with the changes for #740. I guess that is to say that these aren't truly deprecated yet?

[dburgener]

I guess that is to say that these aren't truly deprecated yet?

I would say that marking them #[deprecated] is what makes them "truly deprecated".

There is a chance with this that users running 0.20.1 will get a confusing message that says "process_root_unconditionally has been deprecated since 1.0.0", right?

It's not a huge deal, and I definitely don't want to die on this hill, but it feels inconsistent to me. If we don't want to deprecate process_root_unconditionally until 1.0.0, I think the most correct thing to do might be to revert #799 for now, and remerge between the last 0.x release and 1.0.0.

[Pat-Lafon]

I'm against reverting since there is also

lalrpop/lalrpop/src/lexer/dfa/mod.rs

Line 25 in 2678f89

#[deprecated(since = "1.0.0", note = "use `Dfa` instead")]

which I was trying to say should be treated the same way. I don't think that is revertible without it being a breaking change. Otherwise, I don't have a strong opinion about changing these version numbers to something other than 1.0.0.

[dburgener]

Oh, interesting. I had missed that 0.20.0 already has some of these future-dated deprecation numbers.

Reading up some more on this (https://doc.rust-lang.org/reference/attributes/diagnostics.html#the-deprecated-attribute), it looks like rustdoc shows the since field in a human readable string in autogenerated documentation, rustc ignores it, and all clippy does is check for the version number is valid.

So I'm fine with future-dating these, since that string really only seems to impact documentation. It's a little weird, but probably minor enough to not justify any extra code churn to change anything.

[youknowone]

Oh, when I wrote the patch, I expected the next version will be 1.0.0. But we had to publish 0.20 in urge due to other issues.
0.20 will fit better since we decided to break it in 0.20. (I regard it a version mark bug)

Upvote for new publish. Including #814 will be great

[Pat-Lafon]

@yannham @youknowone @dburgener as mentioned in #841 (comment) it might be worth moving this forward. The pr mentioned of #814 has been merged.

[yannham]

I am all for a new release, but as far as I know I don't have releasing rights. We can prepare for it though, bumping versions and all. Do any of you have? Or is @nikomatsakis the only one, for security reasons?

[youknowone]

I have permission. Could you prepare release note? I have time to do it late today or mid next week.