Shenanigans aside, 0.x versioning is commonly used when developers cannot (yet) make any guarantees about backwards compatibility between minor releases.
This is true and unfortunate, but I think the engineering value of meaningful versions is important and I expect that with enough time people will adapt to understanding a different meaning of 0.x.
And besides, people are right to understand 0.x is risky b.c you are not guaranteeing backwards compatibility.
You're a few years behind: people actually went "haha, good joke... for real tho that's actually how we version, let's make it official" and then started using it in earnest.
There've been plenty of projects that officially use 0.x versioning for years now.
This really should be the term for projects that are perpetually releasing 0.x versions.
Maintainers are free to release their software under whatever terms that they wish, but if you actively encourage people to use your software and do not want to maintain backwards compatibility, then IMO, you should be very honest about that.
Any versioning mechanic that allows for a `0.X.Y` has ultimately failed it's users. There are libraries on almost every package manager that have millions of downloads, thousands of production users, but still pretend they are `0.X.Y` as if that means anything. I mean just think about what this sentence:
zero version still denotes a codebase under development
A human wrote that and said "Yeah, this makes sense to me." All code is under development until it's not.
For stuff I write, as soon as _I_ am using it in production, it's 1.0. That's pretty straightforward and objective. Sometimes I give it a couple weeks in production myself as a beta/rc before I tag it 1.0, to take the pain of early bugs myself instead of foisting it on others. No more than that.
It's not always that simple, and it may not be totally objective down to the timestamp, but we can think of _many_ cases where people kept an 0.x version number _long_ after it was obvious they shoudln't be -- the authors were using it in production, they knew hundreds or thousands of developers were using it in production, they knew they _were_ thinking of backwards compatibility.
React was my prime example before now.
The problem isn't different judgements on grey areas, the problem is people completely ignoring the intent of the 0.x versioning -- so they can maybe sort of pretend they are doing semver, while not doing it at all.
The first time you realize you can't make an enormous backwards compatible change without telling anyone, or you're a jerk -- is another good milestone.
Who cares if sometimes it could have been somewhat earlier or later. I'm pretty sure if everyone actually tried, it'd work out orders of magnitude better.
If 0.x versions just "weren't allowed", it doesn't _reduce_ the temptation people have _not_ to do semver. 0.x is just a big advertisement "We're NOT using semver... yet, but plan to later. And also this software is super unstable and you really ought not to use it in production" And should be understood thusly.
The problem is when people keep using 0.x, but are clearly _not_ sending that signal. Those people should be shamed.
I think this points out how arbitrary software versioning is.
I knew of one company that released their products as v3.0 solely for marketing reasons. I wouldn't stoop to that level, but I have realized that by adding new features as minor version releases, I've lost money that I could have made by rolling them into a #.0 release and charging upgrade fees.
Yes, but intentionally so - 0.y.z versions are meant to allow you to more-or-less try stuff out without inflating version numbers, with the 0. reminding users that they shouldn't consider it ready yet if they need API/feature stability.
To me, 0.x version numbers suggest that a project is not stable and can change in incompatible ways at any time... or be abandoned, even. 0.0.x, even more so. That said, some projects stay in 0.x territory for so long that this no longer applies.
0.0.0 is kind of weird... for some reason it suggests to me that zero lines of code have been written so far. (If there was code, the version number would have been higher.) But this is obviously not the case here. I do wonder what versions they used before this release?
Then again, I know of at least one non-trivial project that used negative version numbers... I guess, in the end, it just means what the developers say it means.
So, either they are using 0.y.z to allow themselves breaking changes whenever, or they are using it as a signal that it's not production-ready, or they are not following semantic versioning.
I can't find support for that interpretation in the Semantic Versioning spec: "Major version zero (0.y.z) is for initial development. Anything may change at any time. The public API should not be considered stable."
That means 0.x software is in "initial development" implying no guarantee on how many bugs it can contain and no guarantees regarding maintainership. Other parts of the spec deals with backwards-incompatible api changes.
I know where your interpretation comes from. It comes from users of software who believe that a 0.x version can be relied upon. Because it works for them and they haven't found any bugs. Software publishers on the other hand, never makes that claim and users to whom stability is important should stay away from 0.x software.
Whenever I see software under v1, I see developers who are afraid of commitment.
There’s nothing special about v1, there’s no reason to keep a useless zero for a decade. At some point you gotta realize you’ve been using the minor version as a major so that v0.39.0 is just v39.0.
Apple recently realized the same thing when they stopped releasing 10.x versions and just did 11.0 after 20 years.
It's not exactly unusual to go to non-zero major versions that way, especially if it's been at 0.x for a while and people are thinking/talking about those versions. No confusion between 0.16 and 1.6 etc.
reply