7 ms·

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

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 4y ago
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#version https://docs.npmjs.com/cli/v8/configuring-npm/package-json#v... https://docs.npmjs.com/about-semantic-versioning 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 4y ago
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 https://docs.npmjs.com/about-semantic-versioning

sph 4y ago

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#version https://docs.npmjs.com/cli/v8/configuring-npm/package-json#v... https://docs.npmjs.com/about-semantic-versioning 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 4y ago

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 https://docs.npmjs.com/about-semantic-versioning