5 ms·

> Upgrading from 1 to 2 implies a larger review is needed, I'd not just check compile/tests. Upgrading from 1.4.656 to 1.4.657 and I don't expect to have to che

> Upgrading from 1 to 2 implies a larger review is needed, I'd not just check compile/tests. Upgrading from 1.4.656 to 1.4.657 and I don't expect to have to check the docs for major changes to how things work. What would you do for upgrading from 1.4 to 1.5? > Dates, pure increments etc don't have this. Right, but most versioning schemes are not pure increments and nor pure dates exactly for that reason. You don't plan to release twice a day when your version scheme is year-based; the second number is frequently used for when it's inevitable, making it a hybrid scheme. Still not compatible with the semantic versioning. Semantic versioning also effectively shadowed a previously widespread decimal-based versioning (e.g. 1.00 < 1.09 < 1.5 < 1.99 < 2.0). There are pros and cons for both formats, but decimal-based versioning makes authors to pick a suitable increment for communicating changes, and forbids them to perpetually delay the major version (which can be a pro or a con, I personally think it's a pro). If semantic versioning simply wanted to codify and mechanize the best practice, it should have instead adopted Debian's [1] which tried a lot to unify existing conventions. [1] https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-version https://www.debian.org/doc/debian-policy/ch-controlfields.ht...

simonw 3y ago
"What would you do for upgrading from 1.4 to 1.5?" I'd read the release notes, and spend a little bit of time thinking about if they impact my project. For a 1.4.1 to 1.4.2 bump, if my (comprehensive) tests pass, I'll land the upgrade.
- lifthrasiir 3y ago
  Yes, the minor version clearly doesn't have much information. Then why should we keep the three-part version number after all?
  - IanCal 3y ago
    It does have information about what's changed. It shouldn't be a patch release and it's not supposed to be a breaking change. Outside of new things it informs you about the work expected with downgrades. Going down in minor versions and you should check for breaking changes or removed functionality.
    - lifthrasiir 3y ago
      > It shouldn't be a patch release and it's not supposed to be a breaking change. Such change is not distinguishable from a patch release because, according to the semantic versioning, both should be trivial to upgrade. In the other words, if the semantic versioning did work as intended, upgrading from 1.2.3 to 1.2.99 and to 1.42.0 should be same to users. If it's not the case, there should have been some breaking change. And clearly this is not how users feel about the minor version increment. > Outside of new things it informs you about the work expected with downgrades. Going down in minor versions and you should check for breaking changes or removed functionality. If you need downgrades the distinction among major, minor and patch versions does not matter because either: 1. The library author has broken the premise of semantic versioning, or 2. You have entirely separate requirements that are not part of the public API (whatever it is) and thus the library author didn't honor them.
      - 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.
  - kibwen 3y ago
    Just because one person doesn't find a piece of information useful doesn't mean that everyone else doesn't. Semver is a useful foundation to build versioning semantics upon, and nothing more. I find all three components to be useful for communicating the scope of changes in any given version, and tools like the OP that enforce these assumptions make semver even more useful. If you think that patch versions are useless, then you're free to omit them in your own libraries.
    - lifthrasiir 3y ago
      I never said patch versions are useless. I pointed out that minor and patch versions in the semantic versioning are not very different from each other, in particular compared with major versions. I do use three-part versions, as people had done much before the semver, but people also have used two-part versions and decimal-based versions, not to mention multiple flavors of four-part versions as well. And tools like cargo-semver-checks are actually useful even in the absence of any versioning, because they directly tell which version is compatible with others. They make semver (or any other versioning schemes) more useful, but semver does not make them useful. If I seem to attack a weird strawman, you are not very wrong. Semver is useless but doesn't hurt much either. Semver can somehow encode one-part and two-part versions as well by appending excess zeros. I'm much more concerned that embracing semver (or really any other alternative versioning scheme) makes us overlook the actual problem---versions may detect but can't fix breaking changes. A vast majority of breaking changes is mechanically fixable, and we all know how it is beneficial. We should embrace a method to reduce perceived breaking changes, not a method to point out possible breaking changes.
      - kibwen 3y ago
        > A vast majority of breaking changes is mechanically fixable, and we all know how it is beneficial. We should embrace a method to reduce perceived breaking changes, not a method to point out possible breaking changes. These seem like entirely distinct goals that should be pursued separately. Yes, from the perspective of a library consumer, any breaking change is a problem. But from the perspective of a library author, there's a crucial distinction between breaking changes that I intended to make and breaking changes that I didn't intend to make. The tool in the OP is for use by library authors, with the goal of eliminating unintentional breaking changes, and thereby reducing the number of breaking changes that my users are forced to endure. And what you're asking for is a tool to be used by library consumers, in order to mitigate intentional breaking changes. Both these tools can exist, and both benefit (at least marginally) from semver. Semver isn't a panacea, it's just the simplest possible foundation to communicate ideas about versioning. It's entirely welcome to invent concepts beyond semver to perform even more advanced communication.
IanCal 3y ago
> What would you do for upgrading from 1.4 to 1.5? Something in between? More checking and a glance over the changelog at least to check for added things I should use. Depends how important the component is and risk to the business. > Right, but most versioning schemes are not pure increments and nor pure dates exactly for that reason. You don't plan to release twice a day when your version scheme is year-based; the second number is frequently used for when it's inevitable, making it a hybrid scheme. Still not compatible with the semantic versioning. Sure, those were the suggested options I was countering. Dates of any form don't tell you much about what's practically changed though. > and forbids them to perpetually delay the major version (which can be a pro or a con, I personally think it's a pro). "Version 2 because it's been a while even though this is a logging change" sounds awful to me, as does "welp we've used our 99 releases so now it's a new big number" or "oh shit we used 1.1 so now we only have 10 releases possible". You don't need to make major revisions. > There are pros and cons for both formats, but decimal-based versioning makes authors to pick a suitable increment for communicating changes, Isn't that largely what semver does? There are three major buckets. Still. My point is that it's not worthless, not that it is objectively better in what is a very subjective area (communication).
- lifthrasiir 3y ago
  > "Version 2 because it's been a while even though this is a logging change" sounds awful to me, as does "welp we've used our 99 releases so now it's a new big number" or "oh shit we used 1.1 so now we only have 10 releases possible". That's not how people used to do decimal-based versioning. They instead tend to be more conscious about the relative amount of changes and how to quantify them. Some changes are worth 0.01. Others are worth 0.1 or 0.05. If many changes are expected before the actual major version, either increments are lowered (say, 0.001 instead of 0.01) or many changes are batched into a single release of the reasonable size. > There are three major buckets. That's too many, I believe---see my other comment. There is a good reason to have at least two components, and authors and/or users may want much finer increments (4 or 5 would be the practical maximum though), but three components as defined by the semver don't seem to be justifiable. I'm not against other existing schemes using three numbers.
  - 3y ago

simonw 3y ago

"What would you do for upgrading from 1.4 to 1.5?" I'd read the release notes, and spend a little bit of time thinking about if they impact my project. For a 1.4.1 to 1.4.2 bump, if my (comprehensive) tests pass, I'll land the upgrade.

lifthrasiir 3y ago
Yes, the minor version clearly doesn't have much information. Then why should we keep the three-part version number after all?
- IanCal 3y ago
  It does have information about what's changed. It shouldn't be a patch release and it's not supposed to be a breaking change. Outside of new things it informs you about the work expected with downgrades. Going down in minor versions and you should check for breaking changes or removed functionality.
  - lifthrasiir 3y ago
    > It shouldn't be a patch release and it's not supposed to be a breaking change. Such change is not distinguishable from a patch release because, according to the semantic versioning, both should be trivial to upgrade. In the other words, if the semantic versioning did work as intended, upgrading from 1.2.3 to 1.2.99 and to 1.42.0 should be same to users. If it's not the case, there should have been some breaking change. And clearly this is not how users feel about the minor version increment. > Outside of new things it informs you about the work expected with downgrades. Going down in minor versions and you should check for breaking changes or removed functionality. If you need downgrades the distinction among major, minor and patch versions does not matter because either: 1. The library author has broken the premise of semantic versioning, or 2. You have entirely separate requirements that are not part of the public API (whatever it is) and thus the library author didn't honor them.
    - 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.
- kibwen 3y ago
  Just because one person doesn't find a piece of information useful doesn't mean that everyone else doesn't. Semver is a useful foundation to build versioning semantics upon, and nothing more. I find all three components to be useful for communicating the scope of changes in any given version, and tools like the OP that enforce these assumptions make semver even more useful. If you think that patch versions are useless, then you're free to omit them in your own libraries.
  - lifthrasiir 3y ago
    I never said patch versions are useless. I pointed out that minor and patch versions in the semantic versioning are not very different from each other, in particular compared with major versions. I do use three-part versions, as people had done much before the semver, but people also have used two-part versions and decimal-based versions, not to mention multiple flavors of four-part versions as well. And tools like cargo-semver-checks are actually useful even in the absence of any versioning, because they directly tell which version is compatible with others. They make semver (or any other versioning schemes) more useful, but semver does not make them useful. If I seem to attack a weird strawman, you are not very wrong. Semver is useless but doesn't hurt much either. Semver can somehow encode one-part and two-part versions as well by appending excess zeros. I'm much more concerned that embracing semver (or really any other alternative versioning scheme) makes us overlook the actual problem---versions may detect but can't fix breaking changes. A vast majority of breaking changes is mechanically fixable, and we all know how it is beneficial. We should embrace a method to reduce perceived breaking changes, not a method to point out possible breaking changes.
    - kibwen 3y ago
      > A vast majority of breaking changes is mechanically fixable, and we all know how it is beneficial. We should embrace a method to reduce perceived breaking changes, not a method to point out possible breaking changes. These seem like entirely distinct goals that should be pursued separately. Yes, from the perspective of a library consumer, any breaking change is a problem. But from the perspective of a library author, there's a crucial distinction between breaking changes that I intended to make and breaking changes that I didn't intend to make. The tool in the OP is for use by library authors, with the goal of eliminating unintentional breaking changes, and thereby reducing the number of breaking changes that my users are forced to endure. And what you're asking for is a tool to be used by library consumers, in order to mitigate intentional breaking changes. Both these tools can exist, and both benefit (at least marginally) from semver. Semver isn't a panacea, it's just the simplest possible foundation to communicate ideas about versioning. It's entirely welcome to invent concepts beyond semver to perform even more advanced communication.

IanCal 3y ago

> What would you do for upgrading from 1.4 to 1.5? Something in between? More checking and a glance over the changelog at least to check for added things I should use. Depends how important the component is and risk to the business. > Right, but most versioning schemes are not pure increments and nor pure dates exactly for that reason. You don't plan to release twice a day when your version scheme is year-based; the second number is frequently used for when it's inevitable, making it a hybrid scheme. Still not compatible with the semantic versioning. Sure, those were the suggested options I was countering. Dates of any form don't tell you much about what's practically changed though. > and forbids them to perpetually delay the major version (which can be a pro or a con, I personally think it's a pro). "Version 2 because it's been a while even though this is a logging change" sounds awful to me, as does "welp we've used our 99 releases so now it's a new big number" or "oh shit we used 1.1 so now we only have 10 releases possible". You don't need to make major revisions. > There are pros and cons for both formats, but decimal-based versioning makes authors to pick a suitable increment for communicating changes, Isn't that largely what semver does? There are three major buckets. Still. My point is that it's not worthless, not that it is objectively better in what is a very subjective area (communication).

lifthrasiir 3y ago
> "Version 2 because it's been a while even though this is a logging change" sounds awful to me, as does "welp we've used our 99 releases so now it's a new big number" or "oh shit we used 1.1 so now we only have 10 releases possible". That's not how people used to do decimal-based versioning. They instead tend to be more conscious about the relative amount of changes and how to quantify them. Some changes are worth 0.01. Others are worth 0.1 or 0.05. If many changes are expected before the actual major version, either increments are lowered (say, 0.001 instead of 0.01) or many changes are batched into a single release of the reasonable size. > There are three major buckets. That's too many, I believe---see my other comment. There is a good reason to have at least two components, and authors and/or users may want much finer increments (4 or 5 would be the practical maximum though), but three components as defined by the semver don't seem to be justifiable. I'm not against other existing schemes using three numbers.
- 3y ago