Project Stars Released Releases Current Version 0ver years
React Native 96,747 2015 359 0.65.0-rc.2 (2021) 6.3
God forbid tor, sklearn, react-native release a v1 -- people might expect things!
They only used single letters:
* https://www.openssl.org/news/changelog.html
The IEEE Ethernet standards are using double letters though:
> * https://www.openssl.org/news/changelog.html
From that link:
> When a release is created, that branch is forked off, and its changelog is also forked. For example, none of the changes after 0.9.8n appear in the other logs, because 1.0.0 was created after that release and before 0.9.8o.
If you look at the changelog in the v0.9.8 branch, you'll see they got up to 0.9.8zh:
https://github.com/openssl/openssl/blob/OpenSSL_0_9_8-stable...
Tor has been around for 17.3 years, now on version 0.4.7.0
Seems getting rock-solid software to >1.0 takes a rock-solid effort.
I guess maybe it's monthly if you count the patch releases? But you can't really claim to "just increase the number by 1 each time" when you have two separate numbers which get incremented for different reasons.
Like at some point just e.g. move from 0.69.0 to some arbitrary number like 7.0.0 or even 70.0.0.
Also, at $WORK we have three separate but related products, each with separate version numbers that we jumped at some point to reach the same value across all 3. One of the products jumped from 3.x to 9.0 I believe.
The reason was that they committed to never to any "major braking change" i.e. that there would never be a version 2.
At the same time the backwards compatibility guarantees didn't work always as good as some people liked so they decided to move from semver to something which is like "only do minor releases, but sometimes imperfect making them somewhat major releases but also somewhat not".
What I advocated for differs in that I want to keep semver. So when you move from e.g. 0.32.0 to 32.0.0 you still would only inc minor version for non braking changes and the patch version for patches.
Through this means that you now can denote path updates, as in 0.32 the minor updates are like major updates and the patch updates are like minor updates.
This can be especially useful when development release speed slows down and you want to make a new release with e.g. just fixing some API docs or just non API exposed bug fixes.
2. what if you need multiple releases in a month, in a day?
3. if it works, don't touch it
The closest ZeroVer comes is to quote Tom Preston-Werner, "If your software is being used in production, it should probably already be 1.0.0." which is something, but could perhaps be dismissed more thoroughly as undesirable or mistaken in this document.
Given the context, I thought for a minute that you were talking about Apple's presentation of the rationale for a successor to Objective-C.
I think, it's a sign of hybris if a project owner goes 1.0 too soon.
We went v1 once we decided our software was ready for other people to use. It meant we'd ensure compatibility via upgrade scripts, and it meant we wouldn't do irresponsible things like tell users "this release requires you to drop your database and start over"
IMHO, if you stay pre 1.0 for years across many releases it means you have too wide a scope for what v1.0 should be.
Essentially, your MVP is v1.0 since that the first viable product you release.
But what sometimes happens is that people imagine v1.0 as being the full vision with everything and so they never really reach it. And of course sometimes it seems that there is no sensible explanation at all for why a product is still pre 1.0 to the point of being ripe for satire, indeed (and ZeroVer is really on point the way it satirises this!).