2 ms·

> Such change is not distinguishable from a patch release because, according to the semantic versioning, both should be trivial to upgrade They're absolutely d

by IanCal 3y ago

> Such change is not distinguishable from a patch release because, according to the semantic versioning, both should be trivial to upgrade They're absolutely distinguishable, they convey a different scale of change. Just because you should be able to blindly upgrade doesn't stop that. If nothing else, it indicates there may be deprecations. You don't want to wait until things break before dealing with those. > If you need downgrades the distinction among major, minor and patch versions does not matter because either You've never had to downgrade a package for other reasons like matching a version used elsewhere? Compared versions of a tool with another developer whole debugging? Downgraded due to an introduced bug? None of those break semver. Again this is about communicating.

lifthrasiir 3y ago
> They're absolutely distinguishable, they convey a different scale of change. Minor vs. patch releases are absolutely distinguishable because authors did say so, but changes are not---unless you actually try to use new features. > If nothing else, it indicates there may be deprecations. You don't want to wait until things break before dealing with those. Deprecations are not breaking changes, so it shouldn't matter anyway. The semver rule of requiring the minor version for deprecations is pretty silly. I do see the intention---give enough time before the actual removal---but the rule is too strong and smells of retrofitting. Semver's unclear distinction between minor vs. patch versions is also visible from the coexistence of "caret" requirements and "tilde" requirements in many semver-enabled systems. The former can upgrade to any minor versions, while the latter won't if the required version is specified in the full three-part form. Which one should I use? Depends on packages? Is that any different from having a different versioning scheme per package? > You've never had to downgrade a package for other reasons like matching a version used elsewhere? Compared versions of a tool with another developer whole debugging? Downgraded due to an introduced bug? None of those break semver. I do a lot of downgrading, but I don't trust semver and at least test them again (and look at actual changes if I can). Bugs do not break semver, but at that point the very reason to trust semver also disappears. Also, consider the case where x.y.0 has introduced a new feature I need and also a new shiny bug. Obviously I can't no longer downgrade and semver offers no other solution. The common way to deal with this is to fork and vendor local changes (I did encounter this situation as recent as 2 months ago). I should note that semver in principle should have prevented this for other x.y.z versions (z > 0), but bugs introduced by x.y.z are much rarer than x.y.0 because x.y.z are supposed to be bugfix-only releases anyway.
- IanCal 3y ago
  > Minor vs. patch releases are absolutely distinguishable because authors did say so, but changes are not---unless you actually try to use new features. I'm not understanding, sorry. There are changes that fit in minor that don't in patch - they're not equivalent. I think we have crossed wires somewhere on this point. > Semver's unclear distinction between minor vs. patch versions is also visible from the coexistence of "caret" requirements and "tilde" requirements in many semver-enabled systems. The former can upgrade to any minor versions, while the latter won't if the required version is specified in the full three-part form. Which one should I use? Depends on packages? Is that any different from having a different versioning scheme per package? Tilde is "this patch and above don't go to a new minor version". Caret is the same but allows minor upgrades. Which you use depends on your project and testing, and yeah you can base it on what the maintainer is like. Some projects break all the time and you don't want even patch releases. I'm not really sure why they added those tbh I'd prefer just ranges. They're just shorthand for ranges anyway. Again, it's about communication. Some people being bad at communicating or maintaining software doesn't make communication pointless. It brings the problem down to one versioning scheme, which you can rely on to different degrees. The overrides are then significantly more contained than having scores of various different things with formats that require different parsing despite looking identical. You instead have one thing and if you're unlucky you have a misbehaving package in your dependencies. > Deprecations are not breaking changes, so it shouldn't matter anyway. Yes, which is why it isn't a major change. This is all about the maintainer communicating with you that this is more than a patch > Also, consider the case where x.y.0 has introduced a new feature I need and also a new shiny bug. Obviously I can't no longer downgrade and semver offers no other solution. Semver doesn't fix bugs no, but I don't understand the problem you're describing. That would be followed by a patch release with the same minor versions number right? How does semver make any claims to prevent bugs being introduced? If it's a local change you make would you have a distinct package? If you want to have the same package name just make a patch number yourself and mark it pre-release. That's literally what it is right - a patch that's not yet released.
- SAI_Peregrinus 3y ago
  Major = Changes an existing API. Minor = Adds new API calls. Patch = Changes the internal behavior, but not the API. SemVer's distinctions are essentially useless for applications (and particularly so for GUI applications), but do make some sense for libraries. SemVer is one-way. Downgrading usually still needs the same care as a major version change. SemVer is mostly intended to limit what the version number conveys. It doesn't add extra info (like, is this a bugfix?) but instead takes that away and forces it into the release notes. Dynamically-typed languages make this harder, because internal behavior and the resulting type signature are less separate than with a statically typed language where an accidental type signature change (e.g. returning the wrong type) will break at build time.

by IanCal 3y ago

lifthrasiir 3y ago

> They're absolutely distinguishable, they convey a different scale of change. Minor vs. patch releases are absolutely distinguishable because authors did say so, but changes are not---unless you actually try to use new features. > If nothing else, it indicates there may be deprecations. You don't want to wait until things break before dealing with those. Deprecations are not breaking changes, so it shouldn't matter anyway. The semver rule of requiring the minor version for deprecations is pretty silly. I do see the intention---give enough time before the actual removal---but the rule is too strong and smells of retrofitting. Semver's unclear distinction between minor vs. patch versions is also visible from the coexistence of "caret" requirements and "tilde" requirements in many semver-enabled systems. The former can upgrade to any minor versions, while the latter won't if the required version is specified in the full three-part form. Which one should I use? Depends on packages? Is that any different from having a different versioning scheme per package? > You've never had to downgrade a package for other reasons like matching a version used elsewhere? Compared versions of a tool with another developer whole debugging? Downgraded due to an introduced bug? None of those break semver. I do a lot of downgrading, but I don't trust semver and at least test them again (and look at actual changes if I can). Bugs do not break semver, but at that point the very reason to trust semver also disappears. Also, consider the case where x.y.0 has introduced a new feature I need and also a new shiny bug. Obviously I can't no longer downgrade and semver offers no other solution. The common way to deal with this is to fork and vendor local changes (I did encounter this situation as recent as 2 months ago). I should note that semver in principle should have prevented this for other x.y.z versions (z > 0), but bugs introduced by x.y.z are much rarer than x.y.0 because x.y.z are supposed to be bugfix-only releases anyway.

IanCal 3y ago
> Minor vs. patch releases are absolutely distinguishable because authors did say so, but changes are not---unless you actually try to use new features. I'm not understanding, sorry. There are changes that fit in minor that don't in patch - they're not equivalent. I think we have crossed wires somewhere on this point. > Semver's unclear distinction between minor vs. patch versions is also visible from the coexistence of "caret" requirements and "tilde" requirements in many semver-enabled systems. The former can upgrade to any minor versions, while the latter won't if the required version is specified in the full three-part form. Which one should I use? Depends on packages? Is that any different from having a different versioning scheme per package? Tilde is "this patch and above don't go to a new minor version". Caret is the same but allows minor upgrades. Which you use depends on your project and testing, and yeah you can base it on what the maintainer is like. Some projects break all the time and you don't want even patch releases. I'm not really sure why they added those tbh I'd prefer just ranges. They're just shorthand for ranges anyway. Again, it's about communication. Some people being bad at communicating or maintaining software doesn't make communication pointless. It brings the problem down to one versioning scheme, which you can rely on to different degrees. The overrides are then significantly more contained than having scores of various different things with formats that require different parsing despite looking identical. You instead have one thing and if you're unlucky you have a misbehaving package in your dependencies. > Deprecations are not breaking changes, so it shouldn't matter anyway. Yes, which is why it isn't a major change. This is all about the maintainer communicating with you that this is more than a patch > Also, consider the case where x.y.0 has introduced a new feature I need and also a new shiny bug. Obviously I can't no longer downgrade and semver offers no other solution. Semver doesn't fix bugs no, but I don't understand the problem you're describing. That would be followed by a patch release with the same minor versions number right? How does semver make any claims to prevent bugs being introduced? If it's a local change you make would you have a distinct package? If you want to have the same package name just make a patch number yourself and mark it pre-release. That's literally what it is right - a patch that's not yet released.
SAI_Peregrinus 3y ago
Major = Changes an existing API. Minor = Adds new API calls. Patch = Changes the internal behavior, but not the API. SemVer's distinctions are essentially useless for applications (and particularly so for GUI applications), but do make some sense for libraries. SemVer is one-way. Downgrading usually still needs the same care as a major version change. SemVer is mostly intended to limit what the version number conveys. It doesn't add extra info (like, is this a bugfix?) but instead takes that away and forces it into the release notes. Dynamically-typed languages make this harder, because internal behavior and the resulting type signature are less separate than with a statically typed language where an accidental type signature change (e.g. returning the wrong type) will break at build time.