> Isn't it well known to be a flawed practice yet?
Care to explain? Why would using semantic versioning, something near universally accepted as a best practice, be flawed in your eyes?
Care to explain? Why would using semantic versioning, something near universally accepted as a best practice, be flawed in your eyes?
Rust has tooling to automatically enforce semver. For example, this tool: https://github.com/rust-dev-tools/rust-semverver
Once you modify a Rust library, it downloads the last released version, compiles it and extracts its AST, and compares it with the AST of the current version.
The diff of the two ASTs tells you what the changes are, and there is a Rust book that documents which changes are semver breaking and which aren't. So if you only add a new function to your crate, the tool says that you can bump the semver patch version or minor version, but if you change the name of a public API, the tool requires you to make a new major semver release.
Setting this tool in CI is dead easy, and will make your CI fail if a PR changes the API of your crate without properly updating its semver version.
The question in my mind is where does semver come into this?
Why do you need three arbitrary and meaningless numbers when a commit hash, branch, or tag would suffice.
Nobody said it fixed all problems. Virtually all dependency management systems struggle with this problem, whether packages use semantic versioning or not.
> Isn't it well known to be a flawed practice yet?
If you agree with that statement, why can't you explain why it is flawed?
The question was why do I think it's both flawed and universally accepted.
Because it is, and it isn't?
These are basic facts.
Have you read the semver spec?
Is your libraries new version compatible with my library?
How can you know?
Yes, it was. While the grammar I used should be pretty clear on what I meant already, here’s an alternative version:
Why would using semantic versioning (something near universally accepted as a best practice) be flawed in your eyes?
Or more simply:
Why would using semantic versioning be flawed in your eyes?
> These are basic facts.
Actually, they aren’t. It’s your opinion (not a fact) and you still haven’t provided a single drawback (flaw) to following semantic versioning despite repeated requests.
> Have you read the semver spec?
Yes, I have. More than once in fact. Have you?
> Is your libraries new version compatible with my library?
Assuming both authors follow semantic versioning faithfully and the previous minor/patch release worked, then yes, it very likely will be compatible.
> How can you know?
If both sides have a well defined API and the authors follow semantic versioning, you should have a good indication that way. That said, as the saying goes, “trust but verify”.
Those are not facts, those are claims. Facts are supported with data, and you haven't given any.
The only fact you have actually provided is that you can't tell facts from claims apart, and that makes it very unlikely that you will be able to provide any actual facts that support your claims.