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