34
Semver violations are common, better tooling is the answer (predr.ag)
submitted 1 year ago by snaggen@programming.dev to c/rust@programming.dev
23 comments fedilink hide all child comments
you are viewing a single comment's thread
view the rest of the comments
[-] sugar_in_your_tea@sh.itjust.works 4 points 1 year ago

That oversimplifies and misses a lot of edge cases, such as:

  • change the meaning of an existing parameter - e.g. an Integer timeout changes from seconds to milliseconds
  • dependency changes, and this package exposes exposes types from that dependency
  • internal refactor changes the order of execution of existing uses (say, a scheduler change in an async library, or event order in a GUI library)

Each of those would be, imo, a breaking change, but an automated semver tool would probably mark them as patch releases. I could come up with more examples, but hopefully the point is clear.

Maybe it's correct 90% of the time, but the last 10% of the time can be really impactful. I think there should be less sigma against major releases. If in doubt, mark it as a major release.

[-] SorteKanin@feddit.dk 0 points 1 year ago

change the meaning of an existing parameter - e.g. an Integer timeout changes from seconds to milliseconds

Ideally you should change the type if you do such a thing, which would cause it to become a breaking change. In this specific instance, you should take std::time::Duration obviously.

dependency changes, and this package exposes exposes types from that dependency

I think that should be automatically detectable?

But yes you're right, in general it's not possible to detect all forms of semver changes. But perhaps at least detecting violations when they weren't meant to be there would be good.

And yea 100% agree with you, people should use the power that is 2.0.0 way more than they currently do.

[-] sugar_in_your_tea@sh.itjust.works 2 points 1 year ago

Ideally you should change the type if you do such a thing

But that's not always possible or desirable. For example, maybe you're largely just passing it through to another library, and that library made a breaking change.

So I don't think we should have semver always handled automatically, it should instead prompt the developer with its best guess, and the developer would ideally only move from patch -> minor, patch -> major, or minor -> major, and never the other direction. But the developer should always be involved in picking the version. So don't just throw it into CI and call it a day, but instead have a CLI tool that suggests it and requires developer approval before making the PR for the version bump.

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

!performance@programming.dev

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
snowe@programming.dev
Ategon@programming.dev
EdTheLegendary@programming.dev
kahnclusions@programming.dev
torcherist@programming.dev