Hey, author of the article here.

> 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.