Stable Software Release System
blog.kronis.dev
blog.kronis.dev
We don't need a new versioning system, we need to educate people to use the existing systems properly.
More systems won't fix the problem, they'll just introduce more ways of breaking stuff.
> I wish you had a tldr of why semantic release is not enough.
1.) Because in practice everyone abuses what MAJOR, MINOR and PATCH mean in semver. I've seen plenty of software packages that have actually had breaking changes between something like 3.4.1 and 3.8.4. This is probably in part due to people lacking discipline or just ways to properly test that nothing will break, but also is our objective reality, so it would be nice to fix it somehow.
2.) Because 3.4.1 and 3.8.4 don't actually mean much to anyone. Ubuntu, Unity, JetBrains products and some other pieces of software have far more meaningful and easy to parse version numbering schemes, so seeing "2004" in the version number would be rightfully alarming, but 3.4.1 would be easily overlooked. I'd argue that when software was released actually matters, at least with the way the industry is currently progressing (e.g. an older release may only support TLS v1.1). Add the latest/stable distinction and suddenly it'd become a bit more easy to reason about whether a version is supposed to be a "bleeding edge" one, or something more boring, yet stable.
3.) With our current versioning, it's not always clear how to get from 3.4.1 to 3.8.4 and whether that's what we even want. Having the versioning somehow address the fact that LTS versions eventually diverge from the new versions, or even allow us to go from the "latest" version to a "stable" one down the road (if we need features before they're considered stable) would make things a bit easier. For example, have a look at this mess: https://docs.gitlab.com/ee/update/#upgrade-paths
Edit:
4.) Furthermore, the very existence of having "stable" versions vs just having "latest" (rolling release) versions would be telling and would allow you to set your expectations in regards to managing new releases and breaking changes accordingly (this is already useful when looking at Docker images in Docker Hub). At the same time, seeing new releases in 2021 for the version 2004-stable-... would also reflect positively upon choosing that package or piece of software for slower enterprise projects, similarly to how MySQL 5.7 still receives updates: https://www.mysql.com/support/supportedplatforms/database.ht...
> We don't need a new versioning system, we need to educate people to use the existing systems properly.
Agreed. We definitely need to do it, but since that's just not happening, it'd be nice to explore options that disallow making these mistakes in the mean time, or make these mistakes really obvious.
> More systems won't fix the problem, they'll just introduce more ways of breaking stuff.
Partially agreed. I think that any system can be improved upon, think of how Git essentially replaced SVN and made branching way easier. Similarly, semver will eventually see either improvements in new versions, or we'll get a better system entirely.
Now, i'm under no illusion that my system is much better than semver, though i'd personally like to use it for a side project or two to explore its advantages and shortcomings, since it has the potential to make things a bit easier, at least in my eyes. Personally, i think that moving versioning closer to how VCS branches work can have some advantages.
2) if you are following the guidelines properly, 3.4.1 and 3.8.4 means that there were no breaking changes, that's all I wanna know from a version tag. If I wanna know more, I'll look at the changelog, which I'd look either way regardless of versioning scheme.
3) how to get from 3.4.1 to 3.8.4: again, if people are following the guidelines, you just bump the version because there are no breaking changes.
4) I don't understand your point here. But you can also have non stable versions in semantic version, like 1.2.3-rc1.
In my eyes, that's the beauty behind that idea: you can bump the year, if you want to create a new version (e.g. corporate policy, a LTS released every X years) even without major changes, but that's essentially another offshoot of the codebase that you have to maintain. This might make you reconsider whether that's worth doing and what your EOL policy is.
Similarly, the system would disallow stable versions more than once a year, which i'd view as a feature, instead of a shortcoming. I'd argue that humans probably have a cognitive limit in regards to dealing with the frequency of updates, so a year seems like a decent limitation to set, especially given how many dependencies (e.g. versions) most software out there has to deal with.
> If you are following the guidelines properly, 3.4.1 and 3.8.4 means that there were no breaking changes, that's all I wanna know from a version tag. If I wanna know more, I'll look at the changelog, which I'd look either way regardless of versioning scheme.
I'd argue that version tags should contain more information, rather than just a reference to which other versions would be compatible. That's definitely not all that i care about. I'd also like to suggest that looking at changelogs isn't feasible with limited resources or lots of dependencies.
For example, i have the following dependency versions in a prod application:
2.8.8
3.0.0
10.2.0
3.9.4
6.1.2
... (not included: another 45 dependencies)
I also probably can't update everything automatically to the latest MINOR or even PATCH version, because some of the dependencies deal with core functionality that doesn't always have unit tests, so figuring out what breaks what must be done with gradual updates and code fixes (i dislike how little other people care for striving towards 100% test coverage, but this is also the objective reality that i'm dealing with).
Contrast that with the following:
2021-stable-5
2021-latest-13
2021-stable-2
2018-latest-41
2014-stable-81
... (not included: another 45 dependencies)
> If people are following the guidelines, you just bump the version because there are no breaking changes.
My argument is that this doesn't happen (reliably enough) and everything we can do to limit accidental breakages is probably a good idea. If we remove the MINOR versions altogether, that already eliminates a class of suspicious code changes: "new non-breaking features", at least in my experience, is a misnomer, since i've definitely seen such attempts break things anyways. That's a risk i don't want to take outside of planned major version upgrades.
For example, if you have a merge request against a branch "2014-stable" in your VCS (assuming the branch names correspond to versions) that contains a new feature, you know that it's probably wrong and doesn't belond in your next maintenance release.
New features belong in the "latest" versions, equivalent to what you'd get with "trunk" or "nightly" versions, if you want to live on the bleeding edge and do rolling releases. They should only make their way into stable versions after being properly tested, without backporting being done - only bugfixes and security fixes should be backported.
> But you can also have non stable versions in semantic version, like 1.2.3-rc1
And yet, that's not the default and therefore isn't done in most of the packages out there. Including such metadata in the default version format has its benefits in my eyes, e.g. you know whether you're about to use something bleeding edge, or something that's more stable. For example, the long term updates that MySQL 5.7 received is a good litmus test for stability in my eyes, it has been updated from 2013 all the way to 2021: https://dev.mysql.com/doc/relnotes/mysql/5.7/en/
If i saw "2013-stable-..." be released in 2021, then i'd instantly know that the dependency passes this test of mine and that probably newer versions will also maintain long term support. It's a bit odd, that software packages don't always have clearly defined EOL policies, like OSes do: https://endoflife.software/operating-systems/linux