> What would you do for upgrading from 1.4 to 1.5?
Something in between? More checking and a glance over the changelog at least to check for added things I should use. Depends how important the component is and risk to the business.
> Right, but most versioning schemes are not pure increments and nor pure dates exactly for that reason. You don't plan to release twice a day when your version scheme is year-based; the second number is frequently used for when it's inevitable, making it a hybrid scheme. Still not compatible with the semantic versioning.
Sure, those were the suggested options I was countering. Dates of any form don't tell you much about what's practically changed though.
> and forbids them to perpetually delay the major version (which can be a pro or a con, I personally think it's a pro).
"Version 2 because it's been a while even though this is a logging change" sounds awful to me, as does "welp we've used our 99 releases so now it's a new big number" or "oh shit we used 1.1 so now we only have 10 releases possible". You don't need to make major revisions.
> There are pros and cons for both formats, but decimal-based versioning makes authors to pick a suitable increment for communicating changes,
Isn't that largely what semver does? There are three major buckets.
Still. My point is that it's not worthless, not that it is objectively better in what is a very subjective area (communication).
> "Version 2 because it's been a while even though this is a logging change" sounds awful to me, as does "welp we've used our 99 releases so now it's a new big number" or "oh shit we used 1.1 so now we only have 10 releases possible".
That's not how people used to do decimal-based versioning. They instead tend to be more conscious about the relative amount of changes and how to quantify them. Some changes are worth 0.01. Others are worth 0.1 or 0.05. If many changes are expected before the actual major version, either increments are lowered (say, 0.001 instead of 0.01) or many changes are batched into a single release of the reasonable size.
> There are three major buckets.
That's too many, I believe---see my other comment. There is a good reason to have at least two components, and authors and/or users may want much finer increments (4 or 5 would be the practical maximum though), but three components as defined by the semver don't seem to be justifiable. I'm not against other existing schemes using three numbers.
> Some changes are worth 0.01. Others are worth 0.1 or 0.05.
You can still do that with semver if you want to try and encode more information and hope that people read your docs to understand what specifically you mean by the size of the changes.
> If many changes are expected before the actual major version, either increments are lowered (say, 0.001 instead of 0.01)
Planning an entire major version and how many releases you have coming up sounds rough. Why not give yourself more room? Make it two numbers not a decimal. You could then add .0 to everything.
> or many changes are batched into a single release of the reasonable size.
I'm not a fan of delaying releasing fixes just because changing a number is hard. But you can still do that! Just increment minor or major and set patch to 0. This also buys you the ability to patch an older minor release!
I kind of get the argument against minor and patch, but think they are usefully different. I can't imagine 5 different parts.
Having a reasonable standard means not having to know the preferences of 100 maintainers.
Is it perfect for everyone? No. Is it fine? Sure. My originally point is that not being perfect doesn't mean it's useless.
> That's not how people used to do decimal-based versioning.
“Completely arbitrary, utterly inconsistent (across vendors, across products from the same vendor, and even within the same product over time) and often marketing driven” is how people used to do decimal versioning, and any claim to the contrary is romanticizing a very messy past.
The grandparent's description is a perfectly reasonable example of what would actually happen.
You can't expect anything from version numbers used for marketing purposes anyway, in fact it was also frequent for such products to have internal version numbers that are much more consistent (e.g. Windows). You can do the exact same thing with the semantic versioning---you don't have to increment by exactly one. That practice is irrelevant here.
Something in between? More checking and a glance over the changelog at least to check for added things I should use. Depends how important the component is and risk to the business.
> Right, but most versioning schemes are not pure increments and nor pure dates exactly for that reason. You don't plan to release twice a day when your version scheme is year-based; the second number is frequently used for when it's inevitable, making it a hybrid scheme. Still not compatible with the semantic versioning.
Sure, those were the suggested options I was countering. Dates of any form don't tell you much about what's practically changed though.
> and forbids them to perpetually delay the major version (which can be a pro or a con, I personally think it's a pro).
"Version 2 because it's been a while even though this is a logging change" sounds awful to me, as does "welp we've used our 99 releases so now it's a new big number" or "oh shit we used 1.1 so now we only have 10 releases possible". You don't need to make major revisions.
> There are pros and cons for both formats, but decimal-based versioning makes authors to pick a suitable increment for communicating changes,
Isn't that largely what semver does? There are three major buckets.
Still. My point is that it's not worthless, not that it is objectively better in what is a very subjective area (communication).