Even Java has two major releases per year these days... they are "mostly" backwards-compatible, but not always as stuff can and is getting removed almost every release.

Most apps I've seen can upgrade to Vite 3 without any changes. While there are breaking changes, there aren't a lot and they're not very big.

Confirming: just upgraded to Vite 3 with a one line change in package.json - no other changes were needed :)

I just started using Vite earlier this week so I was a bit dismayed to see a major version release right after I got my project configured, but my experience was the same as yours. Bumped the version in package.json and I'm good to go. My experience converting a project from CRA to Vite was really smooth too, it only took about 20 minutes.

Yes (exhausting). But there's an addiction to novelty (and a denial that it exists) in JavaScript that inevitably hobbles even the best ideas.

As per semver, they need to update major version if one of their dependency(Rollup in this case) did a major upgrade.

If their own public API hasn't changed, why would semver require that?

Because major dependecy change can break downstream users. Major does not signify that you are delivering big features, it signifies you can break existing apps.

For eg: Consider CRA dependency upgrade from webpack v4 to v5. That change broke a lot of apps due to node not being polyfilled.

If CRA did the change in minor version, then it would have result in breaking changes for many apps and would completely undermine semantic versioning

why are you assuming that a major release breaks compatibility?

That’s what semantic versioning is:

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

What an asinine interpretation. No thanks.

Care to explain why you do believe it is "an asinine interpretation"?

I agree. It's up to the publisher to decide the significance of version numbers. Just because Node does it one way doesn't mean everyone else has to follow suit.

The entire NPM ecosystem is based on semver.

That’s the sole reason for the squiggly marks and carets that exist in every package.json.

Dismissing the very rule package.json is written in just because you don't know what it is?

I'm not the one talking about "package.json." We're talking about software version numbers.

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?

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.

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.

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).

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.

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