SemVer itself isn’t really designed for large applications. I understand it to be much more targeted at libraries consumed by software, and in particular, the version numbering logic is built around the package’s API.
We could apply semver to our API(s), though. Having stronger guarantees around the APIs that Discourse exposes is certainly a worthwhile conversation to have, but I think it’s separate from this one.
Now, I understand you didn’t say we should be compliant with semver – you just said we should stick with using numbers that are compliant with the numbering system specified by semver.
- A normal version number MUST take the form X.Y.Z where X, Y, and Z are non-negative integers, and MUST NOT contain leading zeroes. X is the major version, Y is the minor version, and Z is the patch version. Each element MUST increase numerically. For instance: 1.9.0 → 1.10.0 → 1.11.0.
I think the “leading zeroes” suggestion is the only thing that we would be breaking from if we go that route.
Otherwise, I think any semver library would still be able to parse the version numbers we’re suggesting and order them properly.
All that aside, can you share more about why you think being compliant with a semver numbering system has value?