denoland
Implement the `semVer` module to follow the standard and remove non-standard parts
Currently, I am working on something related to version management, so I need a module to parse versions and the std/semver module works well.
But I found std/semver contains too many things beyond the standard, such as ^ and ~. Some features ,^0.2.3 := >=0.2.3 <0.3.0,even break the standard.
So I'm wondering what is the goal of the semver module, does it need to be compatible with some package managers or just follow the standard?
Personally I prefer to follow the standard. Maybe we can simplify the implementation like https://cs.opensource.google/go/x/mod/+/refs/tags/v0.5.1:semver/semver.go
std/semver mirrors most APIs of https://github.com/npm/node-semver
Some features ,^0.2.3 := >=0.2.3 <0.3.0,even break the standard.
How does this break the standard? I believe these are the extension to the standard, which are common in Node.js ecosystem
Major version zero (0.y.z) is for initial development. Anything MAY change at any time. The public API SHOULD NOT be considered stable.
It seems 0.2.3 is not compatible with 0.2.4 according to the standard
semver(1) -- The semantic versioner for npm
node-semver is designed for npm, not for general use.
I mean the semver module is tightly bound to some package manager (npm), so it's better to have it as a 3rd party module rather than part of std. For example, ^ or ~ can be used to determine version constraints in npm, but no such thing exists in golang
It almost feels like @ah-yu is asking for a "strict mode" for the semver module. I don't particularly see how this is useful, and I'm having trouble coming up with an API for this. I'm thinking something like
semver.valid(someSemverString, { strict: true })
But even then, most of the semver utility functions are specifically designed for extensions to the spec. It's pretty trivial to parse semver otherwise (they literally give a regex string in the standard that @ah-yu linked), so I'm not sure what the usecase for a strict mode would be.
Hi @lino-levan, sorry for the late reply. I just thought that some functions are not part of the specification, so they don't fit in the std.
This may be an immature thought, please ignore it if it doesn't make sense to you.