RFC: Rust SemVer 2 by Stargateur · Pull Request #3266 · rust-lang/rfcs · GitHub

While this might serve as a north star for other RFCs, I feel like this RFC is too big. There are a lot of different points covered to get to the final picture which can cause

• Long discussion times as we iterate in one area and then shift focus to another
• Hard to follow threads
• Easy to overlook different aspects

I suspect you will have a lot more success in moving this forward if you

• Break these into more incremental RFCs, like RFC: Precise Pre-release Deps #3263
• Start with deprecations rather than removals
• Limit breaking changes and aim for them being towards the end of the process

rust-lang/rust#95290 is an example of this incremental approach where one specific topic is made an RFC even though it isn't usable on its own. Once we decide on that RFC, we can then have another RFC with the requisite APIs so the discussion is focused on a single line of thought for each RFC.

CAD97, epage, slanterns, madsmtm, and dtolnay reacted with thumbs up emoji All reactions

I'm not sure incremental change are better for such changes, semver/semver#584 (comment) experience show that even change that should be done are complicated and create security problem. Also, we have no process for depreciation of Rust SemVer 1 in Cargo for now. How do we depreciate behavior of ~ and ^ since we reuse them in Rust SemVer 2 (thus use of ~ with my proposition will emit a warning for Rust SemVer 1 and error for Rust SemVer 2 by default) ? For Rust SemVer 2 rules to work they need to come together not one by one. I can't guarantee that change rule one by one would be nice for Rust. My only claim is that all Rust SemVer 2 rules are nicer for user of Rust. Rust SemVer 1 and 2 have very different approach.

Easy to overlook different aspects

That I disagree, that why I made a "big" RFC, to not overlook the change, to have the final big picture. Thus this focus on the Rules of Rust SemVer 2 not on how Cargo will do, this was out of my skills anyway.

Start with deprecations rather than removals

That not possible for ~ or ^ since we change their behaviour we didn't depreciate them. But we sure can do that for range and ,, 1.0.*, 1.*, 0.0, 0 in Rust SemVer 1.1 and add || in Rust SemVer 1.1. The only case where a user can't replace feature without ~ change is >=1 != ~1 in Rust SemVer 1.

So, first one RFC to depreciate some operator in Rust SemVer 1.1 and add || ? We should be sure we go to a Rust SemVer 2 if we go this road.

And a RFC like use 3263 to clarify ^ for pre-release ? (breaking change)

P.S: Success was not my primary goal, I really take this as a training project that was very interesting, but if you think Cargo should go forward Rust SemVer 2, I will certainly help.

All reactions

P.S: Success was not my primary goal, I really take this as a training project that was very interesting,

FYI I read this as this being purely a learning exercise and that this isn't a serious RFC. Please set expectations like that from beginning, otherwise some of us might put our time and attention to this that we wouldn't otherwise, wasting our time. Without a good clarification on your intentions, I am going to disengage from this and will not have much trust left for engaging in the future efforts to reach out like this. I'm leaving the rest of my response as I wrote it first and figured I might as well not delete it.

---

That I disagree, that why I made a "big" RFC, to not overlook the change, to have the final big picture. Thus this focus on the Rules of Rust SemVer 2 not on how Cargo will do, this was out of my skills anyway.

I was not making a statement on whether you overlooked something but that the discussion of the RFC is likely to overlook something. I've seen this in another RFC where one area got the focus of discussion overshadowing discussions on other areas.

Start with deprecations rather than removals

That not possible for ~ or ^ since we change their behaviour we didn't depreciate them.

That is why this item was focused on removals and not changes of behavior, things like <

if you think Cargo should go forward Rust SemVer 2, I will certainly help.

I am unsure of the value of it; I'm intentionally not reviewing it yet until we have a break down of what should be done so as not to be distracted by the minutia as we resolve more pressing questions.

dtolnay reacted with thumbs up emoji All reactions

FYI I read this as this being purely a learning exercise and that this isn't a serious RFC. Please set expectations like that from beginning, otherwise some of us might put our time and attention to this that we wouldn't otherwise, wasting our time. Without a good clarification on your intentions, I am going to disengage from this and will not have much trust left for engaging in the future efforts to reach out like this. I'm leaving the rest of my response as I wrote it first and figured I might as well not delete it.

Not what I mean, This is a total serious RFC, I put a lot of work on it, I guaranty it's not just random though and I can guarantee it's much better than current state of Cargo, my point is that since I got so many negative comment before even start the first word of this document I expect, very negative comment, thus I set my expectation over this being accepted very VERY low, I mean it's normal, I literally propose the most breaking change ever in Cargo, I don't expect myself that this be accepted. I just want to expose theses problems to the community. I believe most people don't realize the current problem we have.

I do not desire to fight to fix Rust SemVer 1 problems, and your message here just do that, try to be in my place, I'm a long user of Rust, I have done many big project in Rust but mostly closed source, I have done hundred of stackoverflow contribution for Rust but I don't think much care about that in Rust team governance; For you I come from nowhere even if I use Rust since more than 7 years. And so when dtolnay and you and even djc, you all tell me "don't loose your time make this RFC", dtolnay even say the RFC have zero chance, try to be in my place, alone versus giant contributor who attack everything you will do even trying your best. Thus, I take the position to not expect anything from this cause I didn't want to get hurt even if it's already the case and I half wish to come back to the past to prevent me from making the first RFC cause my project who was using a rocket pre-release break without reason.

But if it's accept or if you try to help me to make it happen I will of course help, but I will not fight to impose this even if I think it's better, that why I say I didn't make it to be a "Success " aka "accepted RFC" my point was to present problems, present working and elegant solution, that all. Not to try to impose theses solutions.

I was not making a statement on whether you overlooked something but that the discussion of the RFC is likely to overlook something. I've seen this in another RFC where one area got the focus of discussion overshadowing discussions on other areas.

Well, I can't really "split" this RFC, imagine splitting SemVer 2 RFC, I can try but I think it would be worse, I tried to make the RFC the more easy to read than I could. I could maybe remove the part about guideline for pre-release policy.

I am unsure of the value of it; I'm intentionally not reviewing it yet until we have a break down of what should be done so as not to be distracted by the minutia as we resolve more pressing questions.

I also think this is not urgent, I will improve the RFC over time, try to take into account peoples review. I have already spot some little typo and unclear sentence.

All reactions

I will try to work to split the RFC into smaller part.

All reactions