Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Proposal: Respect semantic versioning requirements or stop using it #2438

Open
corneliusroemer opened this issue Sep 9, 2023 · 0 comments
Open
Labels
enhancement New feature or request

Comments

@corneliusroemer
Copy link
Contributor

corneliusroemer commented Sep 9, 2023

Update: After I posted this, I noticed that there is an issue/RfC for breaking changes planned for version 8. That's a great move forward! See #2409

I really really love snakemake, it's an amazing tool that's getting better and better and I couldn't imagine working without it.

Unfortunately, one major pain point I have observed, and that is discussed at least behind the scenes quite regularly, is the fact that breaking changes are regularly slipped in feature or even patch releases rather than major version releases.

This is compounded by the fact that breaking changes are often also not well documented in the changelog. In fact, I could barely find any mention of the word "breaking" in the changelog. Users of snakemake will know that that's not because there are no breaking changes, in fact they occur quite regularly.

The use of semantic versioning conveys a tacit promise to obey the basic principles of semantic versioning: breaking changes should only be released in major version bumps.

The practice is unfortunately quite different: it's hard to see any clear patterns between what triggers major vs minor vs patch releases. Users new to snakemake have to learn this the hard way.

There are really two ways forward that would reduce user pain:
A) Getting better at following semantic versioning requirements, thinking carefully about whether a new release introduces breaking changes.
B) Stop using semantic versioning and use date based versioning instead. Other projects have made the switch from semantic to date based versioning before, see e.g conda: https://github.com/conda-incubator/ceps/blob/main/cep-8.md

I think either option is OK. I think A) would be preferrable but requires discipline.

B) has the advantage that it clearly communicates to users that if they want to avoid nasty surprises, they need to pin the exact version and can't rely on the use of semantic versioning and pin major version only.

These are the most recent mentions of "breaking" in the changelog. The drop of Python 3.7 was actually released in 7.29 but not mentioned in the changelog at all. The release of 6.0.0 seems to not have been accompanied by any breaking changes at all:
image
image
image

A big breaking change took place in 7.8.0 (see #1694) but isn't mentioned as such in the changelog:
image

Note: These thoughts have been in my head for a while. I decided to write them up when I saw this comment: #2434 (comment) and couldn't find any corresponding mention of this breaking change in the changelog.

@corneliusroemer corneliusroemer added the enhancement New feature or request label Sep 9, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant