3 ms·

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

> 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.
- dragonwriter 3y ago
  > Surely you understand that not all projects use semver SemVer only makes sense for projects whose principal function is presenting what is consumed as a single, unified API, because the first two components of SemVer are actually a version number for the presented API, and the last component communicates the sequential version number without API changes.

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.
dragonwriter 3y ago
> Surely you understand that not all projects use semver SemVer only makes sense for projects whose principal function is presenting what is consumed as a single, unified API, because the first two components of SemVer are actually a version number for the presented API, and the last component communicates the sequential version number without API changes.