> 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:
For React Native we do ~monthly releases and just increase by 1 each time. It’s a train model this way people know when their changes will get released. I guess we should consider bumping to 1.x at some point and keep going :)
Monthly? There were 3 releases in 2019, 2 in 2020, 2 so far in 2021 if you count the imminent 0.65 release.
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.
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.
Java moved from 1.4 to 1.5 and just stopped displaying the 1.
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.
Java / OpenJDK never used semver in the first place. Also, large projects like Java have entire layers of different APIs, whose compatibility guaranties can't really be described with a single number, no matter what versioning scheme they use.
I don't think calling it a joke is correct. It correctly self-describes as satire, which is quite different. Both use humor but one is not meant seriously whereas the other has a serious critique behind it.
A good satire should have a serious point it dismisses as part of the joke. For example Swift's "A Modest Proposal" is famous for its recommendation that Ireland's problems will be solved if the Irish eat their children, but it explicitly dismisses the possibility of taxing "absentee landowners" and other wealthy people and that is what Swift thinks you should actually do.
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.
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"
I think, that's the main problem with SemVer. Everyone tries to merge the major version with some kind of nebulous "readiness". While it should just be a number related to technical aspects of the software.
And I think that is the right way to think about it. I think people stay on 0 because they think they have to implement all ideas and edgecases before it you can call it 1.0. You can also get stuck on 1.x releases in the same way (notably Java).
If you have a set of working, useful features, however small as long as they part of your core product, and you release to the public then you have your v1.0.
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!).
God forbid tor, sklearn, react-native release a v1 -- people might expect things!