You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
A big breaking change took place in 7.8.0 (see #1694) but isn't mentioned as such in the changelog:
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.
The text was updated successfully, but these errors were encountered:
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:
A big breaking change took place in 7.8.0 (see #1694) but isn't mentioned as such in the changelog:
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.
The text was updated successfully, but these errors were encountered: