Post

While I understand the motivation, some of stated benefits and goals are lost along the way. Reasons why I don't think this is a good choice: - Adds complexity - Non-standard in a way that users lose the ability to infer what's going on with major version skips until they read an explanation

- If I'm on vue@65 and `npm i vue@66` fails then I might wrongly assume that v66 isn't released, and that I'm on the latest released major version. This may also break some tools which assume increments in major version by 1.

7/1/25, 2:48 pm0 reposts0 likes

- v125 -> v200 is nice for showing significance however this doesn't hold up at larger numbers e.g. v1125 -> v1200 is arguably worse than v11 -> v12 I think going the other way around and removing complexity is a good approach and worth considering by collapsing patch into minor i.e.

major - intentional breaking change minor - unintentional breaking change (includes bugfixes) I think this is the most important distinction for users, is SemVer compliant, and doesn't require an explanation for users to upgrade versions intuitively

As for epoch changes, named releases work great since a name is more memorable than a release e.g. macOS Sequoia > macOS v15 > macOS v1500 (with epoch semver)