Semver make it easier to spot/prevent mistakes by giving you more granular information. It's not like it's a data overload, so "too much info" as argument is really weird.
Purity in computing is a terrible master.
Semver would be what? Tests should catch it. Mine or yours.
> Bad pushes and releases exist.
Semver would be what? Tests should catch it. Mine or yours.
> Unpatched bugs in latest.
Semver would be what? Tests should catch it. Mine or yours.
> Wrong deployments.
Semver would be what? Tests should catch it. Mine or yours.
> Semver make it easier to spot/prevent mistakes by giving you more granular information.
None of those things are fixed by semver. What is the point of semver again?
The only thing I, as a user, give any crap about is breaking change. i.e. major version numbers.
So why not just have one or two levels?
Oh you care about breaking changes? Ok then for you we will have two levels. Version X.Y it is. For the person above that doesn't care about breaking, two levels still work.
What? You want to show your audience/clients/users that an update contains something interesting for them like a feature, and separate it from a simple typo-fix release? I guess we are adding another level then. Version X.Y.Z is here.
You see, semver is not the ideal way for everyone, but it's the way that everyone can use as they want. As a receiver of a version, you can care about if it's a feature or no, breaking or no, and you set your requirement to a specific number, or ^a number or ~a number etc. As a creator of a version, in order for everyone to work with semver the way they like it, we should be good citizens and try to signify what this version has. Even if you don't care about breaking changes or showing if you just added a feature, try to signify it in your version string. It will help someone.
People ignore deprecation warnings, so the best way forward is often to break compatibility.
I agree that breaking compatibility should be avoided, but it shouldn't be completely out of the question. It needs to be frequent enough that your anticipate it, but not so frequent that you lose users. And you should try to have a bridge between old and new versions (e.g. Rust's "editions" seem like a good idea).
People don't ignore deprecation warnings, they vehemently disagree with their existence. Why the fuck are you taking functionality away from me?
Don't like your thing? Make a new one. The old one isn't hurting you. And if it is, make a new one.
> the best way forward is often to break compatibility.
This is NEVER the best way forward, this is some next level idiotic shit.
> I agree that breaking compatibility should be avoided, but it shouldn't be completely out of the question.
Why not? What in your world view makes this OK? I'm using your software because it solves a problem. I'm not using it so you can make more work for me.
If linux can make backwards compat guarantees since 0.1 then so can libraries like leftpad.
> It needs to be frequent enough that your anticipate it, but not so frequent that you lose users.
Jesus christ, if you think of your users like this I don't think you really deserve them. Your users are why your thing exists, be grateful and stop shitting on their needs for stability.
That is literally what a version is.
Are you supporting old versions?
You don't have to break backwards compat to release new stuff.
It takes some serious design flaws to create a situation where you need more than a handful of foo2 and foo can't be augmented with sane defaults for whatever new side effect is created by foo2.
Breaking change is the only thing I want to know about so realistically I only need to worry about major version updates right?
So lib: 1.* Should be fine, right?
But it's not and when people quip well you should have pegged your versions it's like what? Maybe you shouldn't have broke backwards compat?