I wish you had a tldr of why semantic release is not enough. Imo, semantic release works perfectly well except when people don't follow the guidelines. Same thing applies to the versioning schema described here, it will work as long as people stick to it and it will break if people stop following the guidelines.
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.
1) people would abuse the versions system you described as well. Very stable software that does not include breaking changes would always stay on the same "year" version and they'd feel tempted to bump the year even with not breaking changes. Same for the other way around, people that don't want to wait for the year to end would include breaking changes on a stable release without bumping the year because even if the changes are breaking, they've been tested and are stable.
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.
> Very stable software that does not include breaking changes would always stay on the same "year" version and they'd feel tempted to bump the year even with not breaking changes. Same for the other way around, people that don't want to wait for the year to end would include breaking changes on a stable release without bumping the year because even if the changes are breaking, they've been tested and are stable.
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:
Corporate asks me to update everything that's older than 2 years. The version numbers don't help me in this regard, at a glance. Thus, i'm forced to look up the releases either with a tool to check how old the versions are and what updates exist for the same MAJOR version, or i'm forced to do so manually, especially if i don't have the engineering time to find an automatic solution (and which no one has done so in the past due to a lack of buy-in to spend engineering time on this).
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).
That'd instantly give me hints about how old what is, even in the worst case scenario of no tooling for automation, or no opportunities to use any. Furthermore, "latest" would probably need more attention paid to it than "stable", e.g. the "2018-latest-41" might be upgraded to the corresponding "stable" version.
> 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
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.