[sph]

Because that's the meaning of major version number. Additionally JS/npm modules are supposed to follow semver, and you increment the major version when you break compatibility.

I get it, Linux does its own thing with versions, and so do browsers, so it's hip to just increment major whenever you feel like it apparently.

EDIT: LOL at people downvoting GP because they dared to wonder if the frontend world needs another bundler shipping a non-compatible major version at least once a year. Stockholm Syndrome I guess, who doesn't want to update their configuration and see their plugins break every year?

[zarzavat]

That's one meaning of major version number. The original meaning is simply a release that is significantly different from the previous one. It's also possible to maintain more than one version number: a marketing version and an internal version (Windows did this famously where Windows 7 is actually version 6.1, Windows 8 is 6.2). Then there's a convention where the major version is the year number and it simply increases on Jan 1st, etc.

I have no knowledge of which convention Vite uses.

[fenomas]

In addition to this, I believe it's also kosher to increment a semver major version even without breaking changes. Semver forbids breaking changes without a major version increment, but I don't think it forbids the reverse.

[papruapap]

How do you know they use semver? Major version is just a marketing thing for many frameworks. Node is one of them too.

Even Go, one of the most boring (in the good sense) languages, considered to do the same thing at some point (when included generics).

[sph]

It's not a "marketing thing". The whole version requirement syntax in package.json (i.e. "^1.2.3") and other non-JS package managers really only works if a package follows semver, so that's the reason 99% of JS packages do.

This is why when you npm add a dependency it defaults to the "^1.2.3" syntax, which means the dependency is upgradeable to the next minor version, which, as SemVer states, should be guaranteed to be backwards compatible.

Of course you can just disregard that, make breaking changes whenever you want and annoy your users enormously.

https://docs.npmjs.com/cli/v8/configuring-npm/package-json#v...

https://docs.npmjs.com/about-semantic-versioning

AFAIK Go doesn't follow any kind of versioning scheme (since they don't use a versioned module manager), but the project itself is semver-compliant. No breaking changes are introduced since Go 1.0 was released. The proposals for breaking language changes will be planned for Go 2.0. Generics aren't breaking old code.

There is no reason, unless your name is Linus Torvalds or you're marketing driven such as your browser, not to follow Semver. It's a good and simple idea.

[WorldMaker]

npm itself assumes projects use semver, so it's generally a useful assumption in the JS ecosystem at this point now that npm is the primary package manager for all things JS that JS packages follow semver.

https://docs.npmjs.com/about-semantic-versioning