3 ms·

> "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

> "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.

IanCal 3y ago
> 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.
dragonwriter 3y ago
> 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.
- lifthrasiir 3y ago
  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.

IanCal 3y ago

> 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.

dragonwriter 3y ago

> 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.

lifthrasiir 3y ago
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.