7 ms·

Semantic Versioning 2.0 (2013)

42 points by gorenb 3y ago

koriym 3y ago
2.0.0... Which means they are breaking backward compatibility too.
- bastawhiz 3y ago
  They are. They have changed the conditions that they suggest incrementing minor version numbers on.
- jupp0r 3y ago
  Does the prior version or the new version determine whether a change is a breaking change?
- veleek 3y ago
  Don't worry, this was released ten years ago, so if you haven't run it any issues with it yet you're probably fine.
OJFord 3y ago
It's really unclear from the submission here (no date in TFA either!) but v2 was 'released' 10y ago fwiw. https://github.com/semver/semver/commit/9eca13516c58f0e9456cb2accce266fce330aaa6 https://github.com/semver/semver/commit/9eca13516c58f0e9456c...
- Aeolun 3y ago
  Hah, I was thinking: This sounds like stuff that I’ve seem before to me.
- dang 3y ago
  Thanks! Year added above.
  - innagadadavida 3y ago
    I thought semantic versioning doesn’t use dates like this. Or doesn’t this apply to titles on HN?
    - dang 3y ago
      That's just the HN convention when an article is over a year old.
xjia 3y ago
Diff between 1.0.0 and 2.0.0 https://github.com/semver/semver/compare/v1.0.0...v2.0.0 https://github.com/semver/semver/compare/v1.0.0...v2.0.0
- remram 3y ago
  What are the meaningful changes?
deleted 3y ago
[deleted]
avodonosov 3y ago
The main problem remains not solved: https://github.com/semver/semver/issues/771 https://github.com/semver/semver/issues/771
- tracerbulletx 3y ago
  What does that have to do with the semantic versioning scheme?
- Aeolun 3y ago
  I agree with the first comment on that issue that that is not an issue with semver, and arguably not even an issue with the package manager. It protects you against yourself, and it forces maintainers to keep their libraries up to date less all their users disappear for inability to upgrade.
- bastawhiz 3y ago
  This remains a problem regardless of whether a library uses semantic versioning or not. How would the semantics of version numbers affect whether multiple copies of a library are included in a project?
  - avodonosov 3y ago
    This is answered multiple times in the ticket. > The main problem with the current Semantic Versioning doc is that by not mentioning this issue it encourages developers to break backward compatibility, giving them impression that increased major version number will protect the clients from trouble. > Instead, breaking changes should be discouraged - in majority of cases it is trivial to keep backward compatibility. (For example, instead of altering function behavior, keep the old function as it is and introduce a new function). > If breaking change is still needed, the developer has to make sure the new version of the library can be loaded simultaneously with the old version. In many languages that will require giving the library new identifier, using new namespace / package in the library source code. -------- > In the current form the document is an invitation to break backwards compatibility any time, under a false promise that changing major version number solves all dependency hell issues -------- > Once again, the point of this ticket is to: 1. Remove the false promise that SemVer solves dependency hell by simply increasing major version. 2. Discourage unnecessary compatibility breakages, when it's trivial to maintain compatibility. 3. Several sentences of advice for the cases when comparability breakage is really needed.
ljm 3y ago
Outside of dependencies, application code is basically 1.{infinitely_incrementing_integer} How many application APIs expose v2, v3, v4? You just append to v1 and add proxies to map old APIs to new ones.
- bastawhiz 3y ago
  Nobody uses semantic versioning for online APIs, because it's expensive to maintain all of the existing versions of the API for all of time. That means that you make very few backwards-incompatible releases, which has a tendency to clump your backwards-incompatible changes into large, planned releases. Stripe's API is a great example of this. Semver is meant for library versioning. When they say "API" they mean the API that the library exposes.
  - jupp0r 3y ago
    It's actually quite common to use the major version of semver for API versioning. Users of the API don't get to choose minor and patch versions though, they also don't need to because there's no breaking changes in them (ideally :) ).
    - bastawhiz 3y ago
      Semver is hardly just major version numbers.
  - ggm 3y ago
    Many developers said this to me (about API versioning) when I was a PM and somehow I struggled to believe it was as intractable as they said. I suspect the reality is the human cost of dealing with versioning in an API is the problem. Not that "it can't be done" but that nobody wants to incur the downstream costs in their lived work, either of running a v1 and a v2 binding, or of managing transitions, or of the whole "is a superset capable of managing with the reduced subset" thing. If you want to be light hearted, IPv4 -> IPv6 is a versioning example where clean break is demanded, and we're at 35% worldwide. Clearly, sometimes, you have to wear a 20+ year versioning cost. I used to thought experiment "what if we wrote a complete functional client in python, for every version change we release, and gave it to every client" type ideas. Incur the cost in them, to convert for our benefit. Tech leads always went to no.
RakutenSatori 3y ago
The main difference appears to be about deprecation. From > Minor version Y (x.Y.z | x > 0) MUST be incremented if new, backwards compatible functionality is introduced to the public API. It MAY be incremented.. To > It MUST be incremented if any public API functionality is marked as deprecated. Plus a new section on how to handle deprecating functionality.
andrewguy9 3y ago
https://youtu.be/oyLBGkS5ICk?si=F7R2thY7vkNbbo3a&t=1800 https://youtu.be/oyLBGkS5ICk?si=F7R2thY7vkNbbo3a&t=1800 The semantics of semantic versioning: you might be screwed
- avodonosov 3y ago
  Some people share this view. http://avodonosov.blogspot.com/2014/08/semantic-versioning-is-not-solution.html http://avodonosov.blogspot.com/2014/08/semantic-versioning-i... https://github.com/semver/semver/issues/771 https://github.com/semver/semver/issues/771
  - yardstick 3y ago
    I would contend that this is an issue with namespace collision / poor namespace management than it is an issue with semver. For example when I have a REST API endpoint I always prefix it with /<module>/<major-version>/ - would never expect to host both old and new versions on the same base URL
  - 8n4vidtmkvmk 3y ago
    Well they're wrong and so is their language of choice. Any language that pollutes the global namespace when you import a lib did it wrong. For all of JS's faults, they nearly got this one right. Also, even in JS this is still a problem when you really do want all packages to share the same version of the lib, regardless if you're able to import multiple. Sometimes you just don't want multiple instances. Npm and yarn offer a solution for that too, by forcing a certain version resolution but that then you're on your own if it isn't compatible.
    - avodonosov 3y ago
      A related reply: https://news.ycombinator.com/item?id=37762843 https://news.ycombinator.com/item?id=37762843
- KingMob 3y ago
  The thing is, just updating the name/artifact is a half-assed solution required by existing packaging solutions with a flat and/or non-versioned namespace. If more packaging solutions allowed for graceful coexistence of multiple library versions, this would be a non-issue. The problem isn't really semver vs naming.
jonmayer 3y ago
It's 2023 and I'm still losing the battle in the workplace to build semantic versioning into each of our APIs. them: "Don't worry, we compile the git commit hash in. Sometimes." me: silent sobbing
steveklabnik 3y ago
Hey folks! Don't know why this is here. Hasn't been many changes to semver lately. I would like to get some going, but been pretty burned out after Rust. I'd love to bring the spec in line with the implementations, so it's gonna be a change in theory but not in practice. Happy to answer any questions but won't be around the thread for a bit.
- omershapira 3y ago
  Why are you this handsome. It's not fair
- JTyQZSnP3cQGa8B 3y ago
  Not a question but I’m still bitter that PEP440 is not more popular. It had great ideas that Semver does not implement.
- gorenb 3y ago
  hi, i posted this because i was impressed by semver. i didnt know u worked on the rust book. im extremely impressed. What are some tips about Rust that I could use? As a Rustacean myself, I really need help actually sticking to a project. What are some things that can make my code less verbose too?
  - steveklabnik 3y ago
    Thank you! > I really need help actually sticking to a project I am not sure I can help with that :) Self control is hard, there's so many cool things to build. > What are some tips about Rust that I could use? I'm sorry, this is too vague. > What are some things that can make my code less verbose too? Not all kinds of verbosity are a bad thing. But usually there are libraries to help with this. For example, writing your own error implementations can be verbose, but thiserror can help with that.
    - gorenb 3y ago
      thank you so much for responding! this actually means a lot to me. if there isn't a library for something, should i write my own?
tekla 3y ago
The worst apart about SemVer is that people expect that anything that LOOKS like SemVer follows the SemVer spec, however mediocre it may be. SemVer doesn't count as an Engineering spec, its a bunch of arbitrary shit that you can or not follow, and has absolutely no meaning or enforcement.
- BrianHenryIE 3y ago
  Did you just argue that version numbers that do not have a spec are less arbitrary than the ones that do? Surely its entire point is to (at least attempt to) solve the gripe you seem to have.
aidenn0 3y ago
I just wish so many libraries didn't get compliance with SemVer by never releasing a 1.0.0

42 points by gorenb 3y ago

koriym 3y ago

2.0.0... Which means they are breaking backward compatibility too.

bastawhiz 3y ago
They are. They have changed the conditions that they suggest incrementing minor version numbers on.
jupp0r 3y ago
Does the prior version or the new version determine whether a change is a breaking change?
veleek 3y ago
Don't worry, this was released ten years ago, so if you haven't run it any issues with it yet you're probably fine.

OJFord 3y ago

It's really unclear from the submission here (no date in TFA either!) but v2 was 'released' 10y ago fwiw. https://github.com/semver/semver/commit/9eca13516c58f0e9456cb2accce266fce330aaa6 https://github.com/semver/semver/commit/9eca13516c58f0e9456c...

Aeolun 3y ago
Hah, I was thinking: This sounds like stuff that I’ve seem before to me.
dang 3y ago
Thanks! Year added above.
- innagadadavida 3y ago
  I thought semantic versioning doesn’t use dates like this. Or doesn’t this apply to titles on HN?
  - dang 3y ago
    That's just the HN convention when an article is over a year old.

xjia 3y ago

Diff between 1.0.0 and 2.0.0 https://github.com/semver/semver/compare/v1.0.0...v2.0.0 https://github.com/semver/semver/compare/v1.0.0...v2.0.0

remram 3y ago
What are the meaningful changes?

deleted 3y ago

[deleted]

avodonosov 3y ago

The main problem remains not solved: https://github.com/semver/semver/issues/771 https://github.com/semver/semver/issues/771

tracerbulletx 3y ago
What does that have to do with the semantic versioning scheme?
Aeolun 3y ago
I agree with the first comment on that issue that that is not an issue with semver, and arguably not even an issue with the package manager. It protects you against yourself, and it forces maintainers to keep their libraries up to date less all their users disappear for inability to upgrade.
bastawhiz 3y ago
This remains a problem regardless of whether a library uses semantic versioning or not. How would the semantics of version numbers affect whether multiple copies of a library are included in a project?
- avodonosov 3y ago
  This is answered multiple times in the ticket. > The main problem with the current Semantic Versioning doc is that by not mentioning this issue it encourages developers to break backward compatibility, giving them impression that increased major version number will protect the clients from trouble. > Instead, breaking changes should be discouraged - in majority of cases it is trivial to keep backward compatibility. (For example, instead of altering function behavior, keep the old function as it is and introduce a new function). > If breaking change is still needed, the developer has to make sure the new version of the library can be loaded simultaneously with the old version. In many languages that will require giving the library new identifier, using new namespace / package in the library source code. -------- > In the current form the document is an invitation to break backwards compatibility any time, under a false promise that changing major version number solves all dependency hell issues -------- > Once again, the point of this ticket is to: 1. Remove the false promise that SemVer solves dependency hell by simply increasing major version. 2. Discourage unnecessary compatibility breakages, when it's trivial to maintain compatibility. 3. Several sentences of advice for the cases when comparability breakage is really needed.

ljm 3y ago

Outside of dependencies, application code is basically 1.{infinitely_incrementing_integer} How many application APIs expose v2, v3, v4? You just append to v1 and add proxies to map old APIs to new ones.

bastawhiz 3y ago
Nobody uses semantic versioning for online APIs, because it's expensive to maintain all of the existing versions of the API for all of time. That means that you make very few backwards-incompatible releases, which has a tendency to clump your backwards-incompatible changes into large, planned releases. Stripe's API is a great example of this. Semver is meant for library versioning. When they say "API" they mean the API that the library exposes.
- jupp0r 3y ago
  It's actually quite common to use the major version of semver for API versioning. Users of the API don't get to choose minor and patch versions though, they also don't need to because there's no breaking changes in them (ideally :) ).
  - bastawhiz 3y ago
    Semver is hardly just major version numbers.
- ggm 3y ago
  Many developers said this to me (about API versioning) when I was a PM and somehow I struggled to believe it was as intractable as they said. I suspect the reality is the human cost of dealing with versioning in an API is the problem. Not that "it can't be done" but that nobody wants to incur the downstream costs in their lived work, either of running a v1 and a v2 binding, or of managing transitions, or of the whole "is a superset capable of managing with the reduced subset" thing. If you want to be light hearted, IPv4 -> IPv6 is a versioning example where clean break is demanded, and we're at 35% worldwide. Clearly, sometimes, you have to wear a 20+ year versioning cost. I used to thought experiment "what if we wrote a complete functional client in python, for every version change we release, and gave it to every client" type ideas. Incur the cost in them, to convert for our benefit. Tech leads always went to no.

RakutenSatori 3y ago

The main difference appears to be about deprecation. From > Minor version Y (x.Y.z | x > 0) MUST be incremented if new, backwards compatible functionality is introduced to the public API. It MAY be incremented.. To > It MUST be incremented if any public API functionality is marked as deprecated. Plus a new section on how to handle deprecating functionality.

andrewguy9 3y ago

https://youtu.be/oyLBGkS5ICk?si=F7R2thY7vkNbbo3a&t=1800 https://youtu.be/oyLBGkS5ICk?si=F7R2thY7vkNbbo3a&t=1800 The semantics of semantic versioning: you might be screwed

avodonosov 3y ago
Some people share this view. http://avodonosov.blogspot.com/2014/08/semantic-versioning-is-not-solution.html http://avodonosov.blogspot.com/2014/08/semantic-versioning-i... https://github.com/semver/semver/issues/771 https://github.com/semver/semver/issues/771
- yardstick 3y ago
  I would contend that this is an issue with namespace collision / poor namespace management than it is an issue with semver. For example when I have a REST API endpoint I always prefix it with /<module>/<major-version>/ - would never expect to host both old and new versions on the same base URL
- 8n4vidtmkvmk 3y ago
  Well they're wrong and so is their language of choice. Any language that pollutes the global namespace when you import a lib did it wrong. For all of JS's faults, they nearly got this one right. Also, even in JS this is still a problem when you really do want all packages to share the same version of the lib, regardless if you're able to import multiple. Sometimes you just don't want multiple instances. Npm and yarn offer a solution for that too, by forcing a certain version resolution but that then you're on your own if it isn't compatible.
  - avodonosov 3y ago
    A related reply: https://news.ycombinator.com/item?id=37762843 https://news.ycombinator.com/item?id=37762843
KingMob 3y ago
The thing is, just updating the name/artifact is a half-assed solution required by existing packaging solutions with a flat and/or non-versioned namespace. If more packaging solutions allowed for graceful coexistence of multiple library versions, this would be a non-issue. The problem isn't really semver vs naming.

jonmayer 3y ago

It's 2023 and I'm still losing the battle in the workplace to build semantic versioning into each of our APIs. them: "Don't worry, we compile the git commit hash in. Sometimes." me: silent sobbing

steveklabnik 3y ago

Hey folks! Don't know why this is here. Hasn't been many changes to semver lately. I would like to get some going, but been pretty burned out after Rust. I'd love to bring the spec in line with the implementations, so it's gonna be a change in theory but not in practice. Happy to answer any questions but won't be around the thread for a bit.

omershapira 3y ago
Why are you this handsome. It's not fair
JTyQZSnP3cQGa8B 3y ago
Not a question but I’m still bitter that PEP440 is not more popular. It had great ideas that Semver does not implement.
gorenb 3y ago
hi, i posted this because i was impressed by semver. i didnt know u worked on the rust book. im extremely impressed. What are some tips about Rust that I could use? As a Rustacean myself, I really need help actually sticking to a project. What are some things that can make my code less verbose too?
- steveklabnik 3y ago
  Thank you! > I really need help actually sticking to a project I am not sure I can help with that :) Self control is hard, there's so many cool things to build. > What are some tips about Rust that I could use? I'm sorry, this is too vague. > What are some things that can make my code less verbose too? Not all kinds of verbosity are a bad thing. But usually there are libraries to help with this. For example, writing your own error implementations can be verbose, but thiserror can help with that.
  - gorenb 3y ago
    thank you so much for responding! this actually means a lot to me. if there isn't a library for something, should i write my own?

tekla 3y ago

The worst apart about SemVer is that people expect that anything that LOOKS like SemVer follows the SemVer spec, however mediocre it may be. SemVer doesn't count as an Engineering spec, its a bunch of arbitrary shit that you can or not follow, and has absolutely no meaning or enforcement.

BrianHenryIE 3y ago
Did you just argue that version numbers that do not have a spec are less arbitrary than the ones that do? Surely its entire point is to (at least attempt to) solve the gripe you seem to have.

aidenn0 3y ago

I just wish so many libraries didn't get compliance with SemVer by never releasing a 1.0.0