5 ms·

> Would you feel comfortable doing the update, without checking whether the project still compiles and passes its test suite afterwards? I don't trust saving a

by IanCal 3y ago

> Would you feel comfortable doing the update, without checking whether the project still compiles and passes its test suite afterwards? I don't trust saving a file that hasn't changed without checking if things compile/pass tests. > If you answered "no", then you are basically admitting that Semver is worthless in practice I hugely disagree. Version numbers give me a good idea about what level of changes to expect. 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. Dates, pure increments etc don't have this. Two releases a day apart can be wildly different - a patch release fixing a logging format and a fundamental API change. It's a method of communication . Not being perfect doesn't make it useless.

lifthrasiir 3y ago
> 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
- 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
alpaca128 3y ago
> Version numbers give me a good idea about what level of changes to expect Google Chrome went from version 1.0 to 114.0 in less than half the time in which FreeCAD went from 0.0 to 0.20. Blender once had a huge update that only changed the minor version number...and the entire user interface, among other things. The Linux kernel had major version bumps simply because Linus Torvalds felt like it. No, version numbers give absolutely no indication about what actually happened. > 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 I had node project setups crash and burn because a library had the version X.0.7 instead of X.0.3 and some other library couldn't handle this supposed non-breaking change. Similarly last time I tried ML stuff with python I had to downgrade from version 3.11 to 3.10 to make it work. I can't remember any case of breakage where the difference was actually visible in the major version number. > Not being perfect doesn't make it useless. The only two aspects that prevent it from being useless is that version numbers make it easier to google specific issues and to figure out if the version you have installed is the newest one. But communicating what extent of changes to expect is completely unreliable.
- pests 3y ago
  > Blender once had a huge update that only changed the minor version number Blender was not semver until 3.0 so that is perfectly valid. You can't complain about semver projects and inconsistent versioning and then pull out non-semver projects.
- kibwen 3y ago
  > No, version numbers give absolutely no indication about what actually happened. Surely you understand that not all projects use semver. When projects that do not use semver have version numbers that communicate nothing, that's not a failure of semver. Indeed, you have accurately derived the reason why semver exists: because it would be useful for version numbers to have known semantics. The above comment is, seemingly by accident, an argument in favor of semver.
  - alpaca128 3y ago
    > it would be useful for version numbers to have known semantics Fair point, but then wouldn't it have made more sense to also define a unique syntax for semver? If I can't tell whether a project follows that standard by looking at the version number I still can't rely on it without looking it up. That doesn't mean it's useless, but it's an unnecessary source of confusion. With Rust crates there's also the problem that developers cannot use a different syntax to indicate they don't follow semver - cargo will refuse to compile the project. While it would be nice if all packages followed a standard this will realistically never be the case and enforcing the notation won't change that.
eviks 3y ago
1 to 2 doesn't imply anything strictly from the semver spec, so it gives you no indication in theory In practice major versions signal major changes, but only because many people view these versions as humanver

by IanCal 3y ago

lifthrasiir 3y ago

> 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
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

alpaca128 3y ago

> Version numbers give me a good idea about what level of changes to expect Google Chrome went from version 1.0 to 114.0 in less than half the time in which FreeCAD went from 0.0 to 0.20. Blender once had a huge update that only changed the minor version number...and the entire user interface, among other things. The Linux kernel had major version bumps simply because Linus Torvalds felt like it. No, version numbers give absolutely no indication about what actually happened. > 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 I had node project setups crash and burn because a library had the version X.0.7 instead of X.0.3 and some other library couldn't handle this supposed non-breaking change. Similarly last time I tried ML stuff with python I had to downgrade from version 3.11 to 3.10 to make it work. I can't remember any case of breakage where the difference was actually visible in the major version number. > Not being perfect doesn't make it useless. The only two aspects that prevent it from being useless is that version numbers make it easier to google specific issues and to figure out if the version you have installed is the newest one. But communicating what extent of changes to expect is completely unreliable.

pests 3y ago
> Blender once had a huge update that only changed the minor version number Blender was not semver until 3.0 so that is perfectly valid. You can't complain about semver projects and inconsistent versioning and then pull out non-semver projects.
kibwen 3y ago
> No, version numbers give absolutely no indication about what actually happened. Surely you understand that not all projects use semver. When projects that do not use semver have version numbers that communicate nothing, that's not a failure of semver. Indeed, you have accurately derived the reason why semver exists: because it would be useful for version numbers to have known semantics. The above comment is, seemingly by accident, an argument in favor of semver.
- alpaca128 3y ago
  > it would be useful for version numbers to have known semantics Fair point, but then wouldn't it have made more sense to also define a unique syntax for semver? If I can't tell whether a project follows that standard by looking at the version number I still can't rely on it without looking it up. That doesn't mean it's useless, but it's an unnecessary source of confusion. With Rust crates there's also the problem that developers cannot use a different syntax to indicate they don't follow semver - cargo will refuse to compile the project. While it would be nice if all packages followed a standard this will realistically never be the case and enforcing the notation won't change that.

eviks 3y ago

1 to 2 doesn't imply anything strictly from the semver spec, so it gives you no indication in theory In practice major versions signal major changes, but only because many people view these versions as humanver