3 ms·

While this is probably satire, I sort of agree with it! I always thought you just need two numbers, a.b You increment b when you change something in a backwar

While this is probably satire, I sort of agree with it! I always thought you just need two numbers, a.b You increment b when you change something in a backwards compatible way. You increment a when you make a breaking change. If you are used to semver, it is like ditching the minor version and calling it a patch. a.b is if course isomorphic to the 0.a.b system mentioned here. The disadvantage is downgrading patch-only in semver may now be breaking change in twover but that is a rare edge case IMO.

conradludgate 3y ago
It depends on the library. I personally like the minor vs patch distinction. If I see a patch version I might update immediately because I don't want a known bug in my application, but if I see a new minor feature version I might wait a bit
- diarrhea 3y ago
  Same, but note a minor version encompasses all patches since the last release as well. You could have a single feature and countless bug fixes, but it will only show up as a meagre minor bump, with a suspicious zero in the patch field.
- kzrdude 3y ago
  In theory the patch verison should be painless and always a given upgrade. The minor version might have at least the same number of important bug fixes, it's just coming with a different cost of having larger changes as well. Some fixes only come with larger changes. Like the recently posted rust regex 1.9 release. Only a rewrite of the library fixed some long-standing issues.
zajio1am 3y ago
> You increment b when you change something in a backwards compatible way. Problem is that 'backwards compatible' is not a black-and-white criterion. Most non-trivial development could lead to changes in behavior (or at least in performance) that, while not part of API contract, could still be relevant for users. For that reason, it makes sense to have a.b.c scheme, where 'b' is for regular backwards-compatible development, while 'c' is for targeted bugfix releases, which are hopefully devoid of such behavioral changes.
- quickthrower2 3y ago
  I think you have changed my mind, thanks!

conradludgate 3y ago

It depends on the library. I personally like the minor vs patch distinction. If I see a patch version I might update immediately because I don't want a known bug in my application, but if I see a new minor feature version I might wait a bit

diarrhea 3y ago
Same, but note a minor version encompasses all patches since the last release as well. You could have a single feature and countless bug fixes, but it will only show up as a meagre minor bump, with a suspicious zero in the patch field.
kzrdude 3y ago
In theory the patch verison should be painless and always a given upgrade. The minor version might have at least the same number of important bug fixes, it's just coming with a different cost of having larger changes as well. Some fixes only come with larger changes. Like the recently posted rust regex 1.9 release. Only a rewrite of the library fixed some long-standing issues.

zajio1am 3y ago

> You increment b when you change something in a backwards compatible way. Problem is that 'backwards compatible' is not a black-and-white criterion. Most non-trivial development could lead to changes in behavior (or at least in performance) that, while not part of API contract, could still be relevant for users. For that reason, it makes sense to have a.b.c scheme, where 'b' is for regular backwards-compatible development, while 'c' is for targeted bugfix releases, which are hopefully devoid of such behavioral changes.

quickthrower2 3y ago
I think you have changed my mind, thanks!