3 ms·
> No, version numbers give absolutely no indication about what actually happened. Surely you understand that not all projects use semver. When projects that do
by 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.