Hacker News Reader

> You should still try

Great, you agree then that this tool is useful because it will help you try to predict whether a change will break compatibility.

I can barely follow the rest of your comment. Semver is useful in, at least, a decentralized set of actors trying to minimally cooperate with one another by using a short number to communicate coarse but important information with respect to compatibility. Guess what that describes? A FOSS software ecosystem. So...

> Semver is neither of those things except in a very specific circumstance that almost nobody has.

Nope. I would say FOSS is pretty popular.

> Great, you agree then that this tool is useful because it will help you try to predict whether a change will break compatibility.

No. I guess you didn't actually read what I said, and decided instead to construct a strawman by carving very few words out of it completely ignoring the rest of the words around them.

> I can barely follow the rest of your comment.

Ah ha.

> Semver is useful in, at least, a decentralized set of actors trying to minimally cooperate with one another by using a short number to communicate coarse but important information with respect to compatibility.

It's not any more useful than a system with only either date/incremental (this is newer than that) or major.minor (I promise that this change breaks, and that other change might also break but I hope not) versioning except for the one case I mentioned, which FOSS decentralization has absolutely nothing to do with.

cargo-semver-checks checks almost entirely only major.minor versioning issues. Rust's flavor of semver doesn't impose or demand any particular rules about what is a minor and what is a patch version.

So I'm a bit confused about the position you seem to be arguing against, when the tool and the entire ecosystem are doing exactly what you (AFAICT) consider a good idea.

> Rust's flavor of semver doesn't...

Semver.org says:

  Semantic Versioning 2.0.0
  Summary
  Given a version number MAJOR.MINOR.PATCH, increment the:

  MAJOR version when you make incompatible API changes
  MINOR version when you add functionality in a backward compatible manner
  PATCH version when you make backward compatible bug fixes

Three fields. If you're saying that cargo-semver-checks doesn't need three fields, then you're saying that it doesn't benefit from semver as defined by semver.org.

I don't really follow this comments. It's a bit too rambly and circuitous for me to follow, and I gave it a few tries, but I do admit I'm not the best at reading walls of text.

From what I can tell, you're trying to argue that semver is useless while also saying that not following semver means that you don't get any benefits, but that just doesn't seem like a proper argument, so I'm surely misinterpreting.

I think SemVer is a social construct, but that most of the time we can predict what changes will be breaking. We may get it wrong of course, but that doesn't mean we should throw our hands up and not try.

I added a tldr to the top of my original comment. I hope it helps.

cargo-semver-checks checks for breaking changes. minor and patch versions are defined to be backwards compatible and therefore not breaking. So why would it distinguish.

For tooling it's very hard to detect between a feature and a bug fix so it's almost impossible to automate that series of checks

> minor and patch versions are defined to be backwards compatible and therefore not breaking. So why would it distinguish.

Indeed, why? And yet semver itself does, which is senseless.

Because as a user of semver, I am not checking for breaking changes. I'm checking if I need to update because of a bug.

As a user updating my software it's nice to know the gist of an update at a glance.

As a piece of software looking for breaking changes, it is unnecessary to consider.

> Because as a user of semver, I am not checking for breaking changes. I'm checking if I need to update because of a bug.

Semver doesn't help you do that. If you're on version 1.0.1 of my software, and I update to version 1.1.0 and then 1.1.1, have I fixed a bug that exists in 1.0.1? There's no way for you to know based on the version number.

Knowing whether you need to update because of a bug is something you can only find out from change logs, not from version numbers.

> This notion that just because you didn't add/remove an input or output parameter means you didn't change your API is extremely naive.

If I didn't change the behavior with any set of input parameters valid for the prior version, I haven't broken compatibility.

> because almost no projects in the wild continually preserve separate feature branches with backported bug fixes

Maybe not “continually”, but nore than 0% of real software projects using SemVer do release bug fix releases of m.f.b after feature releases of m.(f+1).0

> The user on the other side of the fence wants the best version of whatever you have that doesn't break compatibility with what they're doing.

They may not, because feature releases may be assumed to have greater risk of expanding the risk surface, whether or not they break backward compatibility.

> If I didn't change the behavior with any set of input parameters valid for the prior version, I haven't broken compatibility.

You don't anticipate that the behavior will change in a way that you care about, but that's not the same as not changing behavior. Different sides of an API nearly always have different definitions of "valid" and "behavior" here, and API documentation is never as concrete as would be needed to prevent that. So are you exhaustively fuzzing the input space? Because if you are, then great. But I bet you aren't. And even if you are, nobody else is.

> more than 0% of real software projects using SemVer...

I carefully said approximately. It gives us some leeway when talking about this without falling into the trap of believing that a small degree of adherence is meaningful.

> feature releases may be assumed to have greater risk of expanding the risk surface

I know it's common for people to feel that way, but there isn't a meaningful interface safety dividing boundary that any of us can point to between development of a feature vs a fix. Code is code is code is code. The developers can either reliably identify when changes will break users or not. If they can, then breaking.nonbreaking is plenty. If they can't, then only a single newer_than_before value is fine.

Like, if you want to argue for a new Dragonwriter's TrustVer where we talk about degrees of belief about whether a change will break something, we can do that. I'm all for it. But more than two values will still not be more useful to the user than at most two (except in the one contractual obligation case I presented), and it won't be Semver.

Compatibility is not the only thing version numbers are used for. If we assume bugfixes are a lot more common than new features, then being able to distinguish versions that contain new features from versions that don't is useful, if only for documentation. And if it's not useful to you then by all means treat increments to minor / patch the same when consuming other libraries, and always bump at least the minor version when you make a new release of your own libraries.

I actually find semver worse than useless for that.

Given two versoins, 1.1.10, and 1.2.18, which is newer? Who knows!

Why do you need to know that?

I suspect they meant the other way around - 1.2.18 is always newer than 1.1.10. But if you're running 1.1.18 and see 1.2.10, it would be nice if it were easy to tell wmhether your bug from 1.1.18 is potentially fixed in 1.2.10 or not.

Actually I didn't. Perhaps the 1.1.x branch is for legacy clients and only gets the occasional crucial backport, where the 1.2.x branch is the active you-should-use-this-one-for-new-stuff version, and sees frequent feature releases. It is the very treatment of semver as being equivalent to a monotonically increasing decimal that I object to.