this post was submitted on 07 Sep 2023
34 points (100.0% liked)
Rust
5938 readers
1 users here now
Welcome to the Rust community! This is a place to discuss about the Rust programming language.
Wormhole
Credits
- The icon is a modified version of the official rust logo (changing the colors to a gradient and black background)
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Semver was literally made to communicate programmatically. But people keep using it for "human" communication instead, like the whole "1.0 means stable" thing.
It was made to do so, but failed from the start exactly because humans got involved. semver's ideals can only happen when tooling generates the version number, not humans.
How can a machine decide if something is a patch, minor, or major release? I guess a major release could be defined by a comprehensive unit test suite breaking, but the others are very much something humans should decide.
Imo, the solution is that people need to be less afraid of major release bumps. Do it frequently and it's not likely to cause issues downstream.
@sugar_in_your_tea If you're interested, I recommend looking at how Elm does it. Elm has automatic semver enforcement in its package system.
The long and the short is
missing stuff: major change
new stuff: minor change
patch: internal implementation change.
I gave a more thorough response with examples to the other user that replied (link on my instance here, but basically there are cases where you could break someone's code with a patch release.
I'm completely fine with using tools to help decide what versions to assign, but in general developers should not hesitate to increment the major version if there's any doubt.