4 ms·

Yea or projects that are forever on 0.x.x pre release so any change can be breaking according the spec (as it is considered experimental) even after having many

Yea or projects that are forever on 0.x.x pre release so any change can be breaking according the spec (as it is considered experimental) even after having many adopters. I can think of at least a few OSS projects like this.

ntlang 5y ago
https://0ver.org https://0ver.org
- cphoover 5y ago
  This made me chuckle, thanks for sharing.
skissane 5y ago
OSS projects can get away with it, but in some other environments – someone will review the release bill-of-materials, see the 0.x.x version, and complain "why hasn't team X adopted SemVer properly?"–or even worse, "Oh no, we are shipping an experimental pre-release version in the next release to customers!". Change the 0 to 1, complaint resolved – even if it is never changed again. No one can tell whether it should be 1 or 2 just by looking at a list of version numbers, they'd need to understand what the actual changes are in each component version, and they probably aren't going to do that. I wonder why OSS projects bother with 0.x.x. If you are never going to change the initial 0 to something else, why not just drop it? So you can do whatever you want while paying lip service to SemVer? Why not just do whatever you want, and ignore SemVer entirely?
- zzo38computer 5y ago
  > I wonder why OSS projects bother with 0.x.x. If you are never going to change the initial 0 to something else, why not just drop it? Possibly due to being unsure, thinking too many changes will be made and they don't want to drop it. > Why not just do whatever you want, and ignore SemVer entirely? If your version number is a single number which always changes, then it will still be compatible with SemVer (since it will be the first number, and the other two numbers are then zero), although not very well in case sometimes it still is compatible you will not be able to upgrade without checking this.
  - skissane 5y ago
    Always incrementing the major version, whether there is a backward incompatible change or not, complies with the letter of the SemVer 2.0.0 spec (but obviously not the spirit) – clause 8 says "Major version X (X.y.z | X > 0) MUST be incremented if any backwards incompatible changes are introduced to the public API", but nowhere does the spec actually say "Major version X MUST NOT be incremented if no backwards incompatible changes are introduced to the public API". However, if you do that, some people will start saying "this component is really unstable, they keep on making backward incompatible changes to it". Some people just look at the version number. I don't like SemVer because I think it encourages focusing on the version number instead of the actual version contents, and because it puts all the focus on the backward compatibility of the public API, when that isn't always the thing consumers of a component should be focusing the most on. If I remove some obscure long-deprecated public API which nobody was using anyway, then following SemVer strictly, I must increment the major version–even if that is literally the only change in that release. Meanwhile, I can radically rewrite the implementation, even create a brand-new backward-incompatible next-generation API – but if I also include a compatibility shim which maps the old public API on to the new one, and if (to the best of my knowledge) that shim is complete (even if it actually contains subtle regressions my testing has failed to uncover), then following SemVer strictly that would be a new minor version only. Consumers should be much more concerned about the second release, but SemVer will mislead them into paying more attention to the first instead.
    - zzo38computer 5y ago
      You do not have to use SemVer if you do not like it, and your considerations are valid and are good points. However, there are other considerations. Allow marking old version numbers as "regressive"; any regressive version number is never considered compatible with any other version, whether regressive or not. Allow a version to have multiple version numbers that alias each other; that might be appropriate in the case of radically rewriting the implementation in a way that is supposed to remain compatible. However, that won't solve everything (nor does it even come close). It is necessary for package maintainers to notice if a version has security problems that older and/or newer versions don't, and to do whatever is appropriate in the given situation. Sometimes a program is compatible with multiple versions of a package even if they are not otherwise compatible (it is related to what you describe). Sometimes a program depends on internal details (or bugs) which are subjected to being changed. Sometimes there are other reasons why a user might not want to upgrade (including hardware compatibility). Sometimes conflicts are possible; depending on the situation there might or might not be a way to resolve this. So, like some other messages mentions, using semantic version numbers won't solve everything, but they won't break everything either. Use or don't use semantic version numbers according to your choice, but whichever way you choose should be documented, and anyone using them should be aware of these considerations. FOSS is helpful that you can fork software and modify it for your use if needed, in case you want some but not all of the changes that have been made, or if you can make your own improvements.

ntlang 5y ago

https://0ver.org https://0ver.org

cphoover 5y ago
This made me chuckle, thanks for sharing.

skissane 5y ago

OSS projects can get away with it, but in some other environments – someone will review the release bill-of-materials, see the 0.x.x version, and complain "why hasn't team X adopted SemVer properly?"–or even worse, "Oh no, we are shipping an experimental pre-release version in the next release to customers!". Change the 0 to 1, complaint resolved – even if it is never changed again. No one can tell whether it should be 1 or 2 just by looking at a list of version numbers, they'd need to understand what the actual changes are in each component version, and they probably aren't going to do that. I wonder why OSS projects bother with 0.x.x. If you are never going to change the initial 0 to something else, why not just drop it? So you can do whatever you want while paying lip service to SemVer? Why not just do whatever you want, and ignore SemVer entirely?

zzo38computer 5y ago
> I wonder why OSS projects bother with 0.x.x. If you are never going to change the initial 0 to something else, why not just drop it? Possibly due to being unsure, thinking too many changes will be made and they don't want to drop it. > Why not just do whatever you want, and ignore SemVer entirely? If your version number is a single number which always changes, then it will still be compatible with SemVer (since it will be the first number, and the other two numbers are then zero), although not very well in case sometimes it still is compatible you will not be able to upgrade without checking this.
- skissane 5y ago
  Always incrementing the major version, whether there is a backward incompatible change or not, complies with the letter of the SemVer 2.0.0 spec (but obviously not the spirit) – clause 8 says "Major version X (X.y.z | X > 0) MUST be incremented if any backwards incompatible changes are introduced to the public API", but nowhere does the spec actually say "Major version X MUST NOT be incremented if no backwards incompatible changes are introduced to the public API". However, if you do that, some people will start saying "this component is really unstable, they keep on making backward incompatible changes to it". Some people just look at the version number. I don't like SemVer because I think it encourages focusing on the version number instead of the actual version contents, and because it puts all the focus on the backward compatibility of the public API, when that isn't always the thing consumers of a component should be focusing the most on. If I remove some obscure long-deprecated public API which nobody was using anyway, then following SemVer strictly, I must increment the major version–even if that is literally the only change in that release. Meanwhile, I can radically rewrite the implementation, even create a brand-new backward-incompatible next-generation API – but if I also include a compatibility shim which maps the old public API on to the new one, and if (to the best of my knowledge) that shim is complete (even if it actually contains subtle regressions my testing has failed to uncover), then following SemVer strictly that would be a new minor version only. Consumers should be much more concerned about the second release, but SemVer will mislead them into paying more attention to the first instead.
  - zzo38computer 5y ago
    You do not have to use SemVer if you do not like it, and your considerations are valid and are good points. However, there are other considerations. Allow marking old version numbers as "regressive"; any regressive version number is never considered compatible with any other version, whether regressive or not. Allow a version to have multiple version numbers that alias each other; that might be appropriate in the case of radically rewriting the implementation in a way that is supposed to remain compatible. However, that won't solve everything (nor does it even come close). It is necessary for package maintainers to notice if a version has security problems that older and/or newer versions don't, and to do whatever is appropriate in the given situation. Sometimes a program is compatible with multiple versions of a package even if they are not otherwise compatible (it is related to what you describe). Sometimes a program depends on internal details (or bugs) which are subjected to being changed. Sometimes there are other reasons why a user might not want to upgrade (including hardware compatibility). Sometimes conflicts are possible; depending on the situation there might or might not be a way to resolve this. So, like some other messages mentions, using semantic version numbers won't solve everything, but they won't break everything either. Use or don't use semantic version numbers according to your choice, but whichever way you choose should be documented, and anyone using them should be aware of these considerations. FOSS is helpful that you can fork software and modify it for your use if needed, in case you want some but not all of the changes that have been made, or if you can make your own improvements.