5 ms·

Semver isn't all that OLD; it came out in 2009, I think? (The SemVer site very helpfully doesn't have any dates on it.) Python, meanwhile, came out in 1991. Not

by cwyers 11y ago

Semver isn't all that OLD; it came out in 2009, I think? (The SemVer site very helpfully doesn't have any dates on it.) Python, meanwhile, came out in 1991. Not having precognition made it difficult for Python to adopt SemVer, and now that they have versioning practices in place there needs to be more than "I like SemVer" as a compelling argument for them to change. Especially since there are reasonable people who have reasonable disagreements with how SemVer works.

mikestew 11y ago
I have nothing to back this up other than my increasingly unreliable memory, but the semantics of SemVer goes back further than 2009. Maybe it wasn't formally written out, but as far back as the 90s that XX.YY.zz could be translated as XX == major changes, breaking changes for APIs, reworked UI for end-user apps. YY == some new functionality, no breaking/major changes. zz == bug fixes. It probably goes back further than that, and it was probably one of those "everybody knows..." kind of things, but it definitely didn't start to be a widely-known definition a measly seven years ago.
- plorkyeran 11y ago
  There were a lot of projects informally using what semver defined, but there were also a lot of other popular versioning schemes. Odd minor = unstable version, even minor = stable version used to be pretty popular and is still used by a few projects. The main thing that helped make SemVer the default assumption was package managers that baked it into the dependency resolution, as until then a project's versioning scheme really didn't matter very much to the users of the project as long as it wasn't completely incomprehensible.
  - jrochkind1 11y ago
    Well, baking it into dependency resolution is a response to the fact that figuring out if there were breaking changes in any given update becomes intractable as your dependency tree/graph gets large (and multi-levelled), when each dependency uses it's own versioning scheme, no matter how comprehensible they are individually.
jrochkind1 11y ago
The argument for semver is obviously "you should be able to tell if there are breaking changes between two versions from the version numbers", not "I like semver". You may or may not be persuaded by it, but that's the point of it.

by cwyers 11y ago

mikestew 11y ago

I have nothing to back this up other than my increasingly unreliable memory, but the semantics of SemVer goes back further than 2009. Maybe it wasn't formally written out, but as far back as the 90s that XX.YY.zz could be translated as XX == major changes, breaking changes for APIs, reworked UI for end-user apps. YY == some new functionality, no breaking/major changes. zz == bug fixes. It probably goes back further than that, and it was probably one of those "everybody knows..." kind of things, but it definitely didn't start to be a widely-known definition a measly seven years ago.

plorkyeran 11y ago
There were a lot of projects informally using what semver defined, but there were also a lot of other popular versioning schemes. Odd minor = unstable version, even minor = stable version used to be pretty popular and is still used by a few projects. The main thing that helped make SemVer the default assumption was package managers that baked it into the dependency resolution, as until then a project's versioning scheme really didn't matter very much to the users of the project as long as it wasn't completely incomprehensible.
- jrochkind1 11y ago
  Well, baking it into dependency resolution is a response to the fact that figuring out if there were breaking changes in any given update becomes intractable as your dependency tree/graph gets large (and multi-levelled), when each dependency uses it's own versioning scheme, no matter how comprehensible they are individually.

jrochkind1 11y ago

The argument for semver is obviously "you should be able to tell if there are breaking changes between two versions from the version numbers", not "I like semver". You may or may not be persuaded by it, but that's the point of it.