People just love LTS and backwards compatibility too much. I'm one of them. But it slows the industry, when you can't do API refactors and have to keep bad decisions forever.<p>I think library authors should be more relentless and break compatibility every few years. We just need some conventions to not do so very often. Like new major version every year, deprecate API on the next major version, remove deprecated API on the following major version. So you have 1 year to rewrite your app if necessary.<p>And supporting old versions for those enterprises who would rather pay than upgrade might be a good source of income.
While this is probably satire, I sort of agree with it!<p>I always thought you just need two numbers, a.b<p>You increment b when you change something in a backwards compatible way.<p>You increment a when you make a breaking change.<p>If you are used to semver, it is like ditching the minor version and calling it a patch.<p>a.b is if course isomorphic to the 0.a.b system mentioned here.<p>The disadvantage is downgrading patch-only in semver may now be breaking change in twover but that is a rare edge case IMO.
I prefer negative versioning for prerelease software. It's like a countdown to when your project will be viable and ready to show to the world.<p>Currently on version -2.-0.-61 of my social media network for dogs. It's getting there!
Maybe it is time to consider INvers, irrational number versioning, as used in eg TeX <a href="https://en.m.wikipedia.org/wiki/TeX" rel="nofollow noreferrer">https://en.m.wikipedia.org/wiki/TeX</a><p>In TeX the version approaches Pi, every new version adds a decimal. Elegant, will hold forever!<p>TeX 3.141592653 is 45 years old.
Its companion Metafont has version number 2.71828182, you can see where this is going.
The purpose of versioning is to communicate something to your users. (It's also necessary to increase over time for package managers to work, but that's an easy bar to reach.) SemVer tries to explicitly define exactly what's being communicated: API compatibility. I think that's great, especially for libraries, but it's neither the whole story nor what's most meaningful for most projects.<p>The most obvious and nefarious example is that the most severe and painful kinds of backward incompatibilities are superficially permissible under SemVer: behavior changes. To confuse the issue even more these behavior changes might be to fix a bug and restore the original or intended behavior of a feature! There's no single best way to communicate that to users through a version number: if libfoo v1.4.3 broke a behavior from 1.4.{0,1,2}, should the fix be in v1.4.4 or v1.5 because technically you're creating a backward incompatibility! Does the answer change if the buggy behavior has been around multiple patch releases or multiple minor releases? Does the scale of the behavior difference impact the versioning scheme chosen? Does the approximate number of users impacted impact the versioning scheme chosen? Probably!<p>ZeroVer is, in my opinion, a hacky but fine solution to this: no guarantees! The developers just want to develop and it's up to the consumers of the project to figure out what release they want to use. ZeroVer is when a project chooses not to try to communicate very much through version numbers. I think that's often better than some strict adherence to SemVer that falls apart under any sort of reasonable scrutiny.<p>I like how browsers have gone: basically give up on the traditional Major Version Number. A Chrome 2 or Firefox 2 that is a radical redesign would probably be an entirely new product with new branding and versions. So just bump the first number a lot to communicate feature releases to users, and bump the other numbers for basically internal build reasons. The minor, patch, and build numbers are free to be used and abused for a lot of complex purposes incredibly complex and popular projects like browsers (and operating systems) have.<p>I think a lot of projects, Nomad included, would probably be best represented by BrowserVer. Nomad is deeply committed to incremental improvements and backward compatibility, so any "Nomad 2.0" efforts are more likely to happen under a new project. Frankly Nomad 1.0 was more about marketing than any sort of meaningful feature or compatibility promise: we wanted to communicate Nomad was stable and reliable. Going from 0.x -> 1.x is an easy way to communicate that even if nothing more significant happened from 0.12 -> 1.0 than had happened from any 0.X -> 0.Y.
I'm actually interested in practical examples of alternatives to Name+SemVer for<p>(1) data analysis oriented code
(2) code to run experiments (e.g. psych paradigms)<p>I often find that in such code, forking is rather more common. That is, the code bases become wider rather than deeper. For example, we might run several experiments that have a strong resemblance to each other, but have any number of (experimentally relevant) tweaks. Within each fork, I rename, and restart the semantic versioning.
Discussion in 2021:<p><a href="https://news.ycombinator.com/item?id=28154187">https://news.ycombinator.com/item?id=28154187</a>
I noticed this the other day while writing a small server in Python. FastAPI is 0.100, fine. But I was surprised to find:<p>- Uvicorn is 0.22<p>- httpx is 0.24<p>- starlette is 0.28<p>And so on and on. More generally, the quality of Python's tooling and ecosystem is astonishingly low compared to the investment that every day pours into it.