[RRFC] Allow packages to declare a schema for what kind of versioning system it uses (Allow use of non-SemVer)

[Nixinova]

Moved from nodejs/node#54016

What is the problem this feature will solve?

Many popular projects do not use SemVer. Take Microsoft/TypeScript (microsoft/TypeScript#14116) or jashkenas's packages (jashkenas/underscore#1684). These package maintainers do not follow the implicit contract of using SemVer, sometimes due to fundamental opposition to SemVer itself (https://gist.github.com/jashkenas/cbd2b088e20279ae2c8e).
This leads to friction among users:

I'm concerned that not following semver is creating unnecessary friction for TypeScript consumers who are opted in to having their builds broken whenever TypeScript releases a minor version as npm locks down to only major versions by default.
– microsoft/TypeScript#14116 (comment)

The obvious solution is just to go "not npn's problem - they should be using Semver!" - but that's not going to happen.
We as package consumers are stuck with having to be aware that many critical packages do not follow the expected semantics of SemVer.

What is the feature you are proposing to solve the problem?

Therefore, npm should have a built-in solution for allowing package maintainers to decouple themselves from SemVer.

My proposal is to have an entry in package.json that defines what Versioning schema the package shall use.

I have a drafted schema definition file (schema.json) that defines aspects such segment types, ordering, and which digit increments represent breaking changes.
The default position of package.json would obviously be the use of SemVer, which I have a drafted schema for (semver.schema.json).
These drafted schemas could be adapted and maintained by npm to allow an official API for package maintainers to create their own versioning schemas to use in their projects.

This versioning schema would then be checked when installing a version from a range declared in the package.json (like package@^2.3.0), where the semantics for ^ are "the highest non-breaking version after or including 2.3.0", with what counts as "non-breaking" defined by the provided schema.

Real world example:

If Microsoft declares that for their typescript package, both the first and second digits represent breaking changes (declared using an in-house versioning schema linked to from package.json) -- then installing ^5.2 would not install version 5.5.2 (as expected from SemVer semantics), but only install the highest non-breaking version (which would be something like 5.2.3).

What alternatives have you considered?

"Just use SemVer", but this is not a realistic outcome as us consumers have no way of forcing maintainers like Microsoft to switch from their 'marketing versioning' to use SemVer.

---

This is similar in reason to this stale/unseen proposal npm/npm#19231 but goes quite further beyond by allowing the entire semantics of a version to be user-defined instead of just saying which digit is the breaking digit.
Having this functionality be more complicated than just setting a string is better as it would discourage usage of non-semver versioning - this proposal is for package managers that really, really, really don't want to use semver for some reason or another.

[reggi]

I think semver is such an integral and highly coupled part of npm, especially around dist-tags, tarball names, packuments, and API endpoints, that I don't see a future where the versioning system is abstracted in any way for npm. I don't truly understand the need here either. Just because semver encourages a specific practice, it's ultimately up to package authors to abide by those rules in a way that benefits their users. You could throw it out the window and never properly address breaking changes; you could use major and minor versions and not patches. I don't understand why you would, but maintainers can.

[Nixinova]

Fair enough