5 ms·

It's the opposite, it's the promise that minor version bumps do NOT break things.

thaumasiotes 4y ago
slowmovintarget is right. The default expectation was that things didn't break. Version numbers increased on release. Semantic versioning said to stop basing version numbers on what version of the software you're talking about, and instead use them to indicate that you just broke everything. This only makes sense if it becomes OK to break things. That was an assumption that semantic versioning brought us.
- slowmovintarget 4y ago
  We're getting downvoted, not because we're wrong, but because SemVer doesn't deliver in practice what the documentation claims it provides on paper. What it actually delivers: - 1.2.changed -> don't care - 1.changed.0 -> don't care (at least I'm not supposed to have to care) - changed.0.0 -> you're screwed (maybe, on you to check) SemVer is an agreed upon way to ship breakage.
- dwattttt 4y ago
  That was very much not the default expectation; expecting that things wouldn't break would mean you could update with no oversight, and I don't know a time when that was ever expected. Things broke all the time, the default expectation was that _something_ would need work, it was just a matter of how much. Semantic Versioning just gives us a framework to (try) to know in advance how much work it would be.
happytoexplain 4y ago
I assume the parent's point is that without an agreement similar to SemVer, you never have permission to break things, but of course people break things anyway because APIs must evolve. Something like SemVer allows you to clearly separate things that are and are not "broken", thus in a sense giving you permission to break things.
wahern 4y ago
One of the problems here is recursive cross dependencies--libfoo switches to a major upgrade of libacme 2.x, while libbar remains with 1.x. Even in a language or environment where 1.x and 2.x could in theory coexist, the potential for bugs is often significantly increased. Ideally, before someone decides to inflict their open source code upon the world, they should at least nominally commit to 100% backwards API compatibility. That sets the correct frame of mind, both as a maintainer but also wrt designing and implementing your API. For example, these days all new syscalls on Linux are expected to have a flags argument and strictly reject undefined combinations of flags and arguments. There are exceptions, but that's the baseline expectation; even when excepted, those expectations help steer the conversation to expose potential compatibility traps. And they do this because Linux nominally promises 100% backward compatibility, regardless of versioning; though it took them many years to appreciate the need for those particular technical guard rails. If and when you need to break your promise of 100% backward compatibility (as even Linux occasionally does), then use Semantic Versioning to help smooth the way and set expectations. (I'm agnostic, but certainly semantic versioning was normative long before "Semantic Versioning" existed.) But if your answer to API compatibility starts with Semantic Versioning, then I wouldn't want to have anything to do with your library. It's like asking a bank what their approach to risk management will be and they answer, "following regulatory guidelines". It's not actually a substantive answer to the question, and suggests that one should avoid that bank.
Gigachad 4y ago
You'd be insane to rely on this. A major number bump is only a heads up about something that has broken, but every single change has the possibility of breakages.
- jonny_eh 4y ago
  Right, it's a promise. Write unit tests.

slowmovintarget is right. The default expectation was that things didn't break. Version numbers increased on release. Semantic versioning said to stop basing version numbers on what version of the software you're talking about, and instead use them to indicate that you just broke everything. This only makes sense if it becomes OK to break things. That was an assumption that semantic versioning brought us.

slowmovintarget 4y ago
We're getting downvoted, not because we're wrong, but because SemVer doesn't deliver in practice what the documentation claims it provides on paper. What it actually delivers: - 1.2.changed -> don't care - 1.changed.0 -> don't care (at least I'm not supposed to have to care) - changed.0.0 -> you're screwed (maybe, on you to check) SemVer is an agreed upon way to ship breakage.
dwattttt 4y ago
That was very much not the default expectation; expecting that things wouldn't break would mean you could update with no oversight, and I don't know a time when that was ever expected. Things broke all the time, the default expectation was that _something_ would need work, it was just a matter of how much. Semantic Versioning just gives us a framework to (try) to know in advance how much work it would be.

happytoexplain 4y ago

I assume the parent's point is that without an agreement similar to SemVer, you never have permission to break things, but of course people break things anyway because APIs must evolve. Something like SemVer allows you to clearly separate things that are and are not "broken", thus in a sense giving you permission to break things.

wahern 4y ago

One of the problems here is recursive cross dependencies--libfoo switches to a major upgrade of libacme 2.x, while libbar remains with 1.x. Even in a language or environment where 1.x and 2.x could in theory coexist, the potential for bugs is often significantly increased. Ideally, before someone decides to inflict their open source code upon the world, they should at least nominally commit to 100% backwards API compatibility. That sets the correct frame of mind, both as a maintainer but also wrt designing and implementing your API. For example, these days all new syscalls on Linux are expected to have a flags argument and strictly reject undefined combinations of flags and arguments. There are exceptions, but that's the baseline expectation; even when excepted, those expectations help steer the conversation to expose potential compatibility traps. And they do this because Linux nominally promises 100% backward compatibility, regardless of versioning; though it took them many years to appreciate the need for those particular technical guard rails. If and when you need to break your promise of 100% backward compatibility (as even Linux occasionally does), then use Semantic Versioning to help smooth the way and set expectations. (I'm agnostic, but certainly semantic versioning was normative long before "Semantic Versioning" existed.) But if your answer to API compatibility starts with Semantic Versioning, then I wouldn't want to have anything to do with your library. It's like asking a bank what their approach to risk management will be and they answer, "following regulatory guidelines". It's not actually a substantive answer to the question, and suggests that one should avoid that bank.

Gigachad 4y ago

You'd be insane to rely on this. A major number bump is only a heads up about something that has broken, but every single change has the possibility of breakages.

jonny_eh 4y ago
Right, it's a promise. Write unit tests.