Hacker News Reader

Comment by stormbrew | Hacker News Reader

I mean, yes, sure. But the spec is not the world, and there is a general trend towards literally forcing things to adopt semver even when it makes little sense.

If you write a project in rust, for example, you must give it a semver number in your cargo.toml. You can give it one that makes no sense and maybe never change it or change it arbitrarily, but the implication of that field is always that it's semver. It's right there in the docs: http://doc.crates.io/manifest.html

This is a real procedural problem that is being created by a "silver bullet" approach to versioning that the semver people can deny they're trying to create, but is happening anyways.

View on HN

Given that the article did a poor job of actually stating the problem of semver, could you list the issues you encountered when dealing with rust's use of semver?

I worked at Amazon for 1 year. They use semver for everything. I think that's one of a few technical superiority I missed since left. I am curious about its problems.

The article did not say much. As for the suggestion given in the article, I cannot help to think that one can always release a number based on a semver to external customers. That does not prevent semver being used internally at all.

> a general trend towards literally forcing things to adopt semver

This statement assumes that semver is bad if forced universally, which may or may not be the case.

Your comment include no fact that this is bad. When you mentioning rust, you also did not say anything why semver is bad.

I mean, if someone put an arbitrary number there, and users are screwed because of author fails to maintain the correct contract, at least people can go to there and point out that the contract is broken. Removing semver does not do anything good. It just give the author an possible excuse, i.e., if users are screwed, the author can claim that he/she never meant to make its software backward compatible. For that, semver also provides the same mechanism, i.e., bump a major version number. At lease users know that they can expect a breakage.

The article is poor, I'll agree with that. But the project I work on that makes me agree with it (that does not currently use rust, but it is something we're looking at) is a low level system component that is continuously deployed across entire clusters. We only ever have two versions active in a cluster at a time (either upgrading or downgrading when something goes wrong). People do not really 'consume' us except in so far as the system as a whole does expected things. We do have some "API"s to our system, and we do version those, but those protocols change extremely infrequently and are either only for consumption by the same or adjacent versions.

Our release version numbers are literally jenkins build numbers. Anything else is not worth the administrative overhead for our needs (even were that 'small', it's also weirdly political in a bikeshed sort of way).

And I don't think this is really all that uncommon even for higher level things. I don't think semver makes any sense for a rails app, for example, but in rubyland you only version things you publish. Rust makes you version things you will never publish.

Don't get me wrong. For the things we consume from outside our team or abroad, semver is an absolute boon. Sometimes, though, when you point out that people are treating something as a silver bullet, you're saying it's outright bad. I'm not saying that. It's not a problem with semver that semver is not universally applicable.

If your issue is with the format and the contract that semver enforces, then you can easily number your builds <jenkins build number>.0.0 That's valid semver, it follows the contract. Major versions may break compatibility or may not. There's no contract that enforces that non-breaking changes can only go into minor or patch releases. The only baggage you'll be carrying around will the the two trailing zeroes. You're unlikely to run out of available major version numbers any time soon.

For this scenario you seem more opposed to the idea of version numbers in general then Semver. Does your build process tag the build numbers in your code repository? The benefit of Semver (and any sensible versioning system) is that whatever you deploy in production gets a (human readable) version assigned to it, and that version is tagged in your git/hg/svn repo.

The nice thing about version numbers such as Semver is that whenever you do need to maintain more than one branch of your library/tool/application, its just a matter of branching the code, and assigning a higher major version to the newer branch, whilst keeping the older major version for the stable older branch (which will still receive fixes).

With build numbers you lose a way to distinguish these two, with Semver you have an old branch (v1.0.0, v1.0.1, v1.1.0, …) and a newer branch (v2.0.0, v2.0.1, …) that can both receive new updates and version numbers. Because you usually can't predict which internal project will by necessity get split into two parallel development branches, you might as well just use version numbers everywhere.

I don't quite get the administration argument you mention. A lot of modern build software (Rust is mentioned, but Java does this as well with Maven) use some sort of versioning to facilitate this out of the box, so why go out of the way to not use them?

Why not just have the commit hash?

Version numbers seem to exist purely so proprietary vendors can obfuscate their source code a bit.

If I have the commit hash I can go straight to the exact source code version.

Taken to its logical end goal, really I want three things: commit, upstream branch, and where to find the code.

With those 3 and a little bit of tooling I should be able to go from a version number to the commit log of the current compatible upstream (I guess I'm implying a branch == backwards compatibility but just getting the commit log of really what I want)

We don't need semantic versioning in open source - we need a common immutable web which lets us search on the things which matter.

A commit hash indicates no sequence or logical ordering. With a version number I know that libfancy-1.0.1 was released after libfancy-1.0.0, and in the release notes (as well as the source code repository where the corresponding commit is tagged with the version number) I can easily answer the question “What changed between version 1.0.0 and 1.3.4?”.

Just the SHA1-hash makes this all needlessly opaque — I'm a human, not a machine.

> Version numbers seem to exist purely so proprietary vendors can obfuscate their source code a bit.

Whatever makes you think that? From what I have seen free software projects tend to apply their version numbering schemes with a lot more reliability than proprietary software vendors. And of course version numbers don't obfuscate; any developer worth his salt using version numbers will tag the corresponding commit in the source code repository, and any build environment worth working with will provide a 'release' command that does this automatically.

Ordering is very different to what semantic versioning is. Semantic versioning proposes that those numbers have meaning and it's important.

Whereas again, what you and I are both saying is "who cares, I want the commit".

Commit + Branch means I can answer the question "is my problem fixed (or are things broken) in the newest version of the code" - which is the actual question semantic versioning proposes to answer but can't.

Adding a release number for human readability is fine (i.e. imply some quick ordering so you can go "oh, this isn't the newest version"). But even then: when putting together systems, that's not a question I ever really find myself asking - the one I'm asking is "are these things exactly the same, and what's the latest I can upgrade to without breaking it (or conversely: which was it working fine on).

Which is why I point out the need for an immutable web at the end there: if we accept version ranges are useless for doing reliable ops work (I believe they are - i.e. you will be testing everything anyway), then in order to know anything about what does and doesn't work, I need the source code and commit logs. I probably don't want to include all of those in every release and I do want to be able to get to new versions, thus the three things I need: upstream location, upstream branch, and commit hash. Everything else is irrelevant, or sugar.

EDIT: And we can derive simple ordering numbers anyway - just count commits on the release branch since the product started. Accomplishes the same thing.

EDIT 2: It's also worth considering though, that incrementing numbers introduce subtle bias - people always want the highest number, and assume it must be better. There's always an urge to upgrade to version 2, even if version 2 might be a complete rewrite and less developed then 1 with an uncertain future. How different it might be if we only talked about branch names and commits - we're on the "beach" branch, but the company has a got a new one for the product called "forest". How different might discussions about "upgrading" be, and consideration of security fix deployment and status.

> Whereas again, what you and I are both saying is "who cares, I want the commit".

I (not the grandparent poster) usually don't just want the commit. I want to be able to look at two versions and have a good idea if they're source and/or binary compatible.

If I do need to deal with the source of the app, hopefully they're doing me a solid and tagging commits with the version number.

> Commit + Branch means I can answer the question "is my problem fixed (or are things broken) in the newest version of the code"

Sure, if you want to sift through a VCS log, which I don't want to do. I want a changelog file that tells me what's in the version I'm running, and all versions previous. That answers that question too, and maintaining a changelog (even if you just dump the output of git's shortlog into it every release) is just a responsible part of release engineering.

> ...which is the actual question semantic versioning proposes to answer but can't.

No it doesn't. Semver exists to help answer the API/ABI compatibility question. It has nothing to do with whether or not your bug is fixed or not.

>> ...which is the actual question semantic versioning proposes to answer but can't.

> No it doesn't. Semver exists to help answer the API/ABI compatibility question. It has nothing to do with whether or not your bug is fixed or not.

But it has everything to do with whether other things are broken (i.e. incompatible) which is what determines whether I can upgrade or need to triage. So yes, the question is "whether my bug is fixed and I can use the fix".

The problem is compatibility is a useless theory when you actually need to deploy to production - it either works or doesn't, and if going from version 1.0.0 to version 2.0.0 requires the same amount of testing as going from 1.0.0 to 1.1.0 then I don't know what's been accomplished. Same story with changelogs.

Going from version 1.0 to version 2.0 of a dependency might require rewriting your code, which, unlike testing, we still haven't automated.

Er, I don't know anything about rust but cargo is a package manager, right? And the version field you're referring to is what will get checked if someone declares a dependency against your package, right? And you're saying semver makes little sense for that?

Yes, cargo is the package manager, but it is also the build tool. Whether it's a library or a terminal project (one that has nothing depending on it) you use cargo to build it and it has a Cargo.toml. Even if nothing will ever use your package you will always have to have a version field defined in it.

Which makes sense. First of all, cargo can't know that nothing will use your package. And second of all, it is possible that this will change once someone sees how great package you've built. OTOH it costs you nothing to put a number there and never change it if there is no need.

It can now that it's not exporting a library and only building executables though.

Libraries for shell scripts are made from executables!

Are you suggesting that the field should be optional, or that having the field conform to semver should be optional? If the former, then fair enough but that's orthogonal to the thread. If the latter, that would destroy the package manager's ability to resolve dependencies, right? (Unless new extra metadata was added, or somesuch.)

Either way, requiring semver formatting here sounds like its entirely justified.

I agree with you, semver doesn't make sens for every project. But it still make sense for a lot of executables, and not only library, let me illustrate that.

Let say you create a cli tool, with a given set of command-line parameters. These parameters are the API your programming is exposing. I can use your program from a shell script for instance, and I will use the existing interface. If, in the next release, you change the options your cli program is accepting, you are actually breaking compatibility with existing integrations including my shell script. Hence this is a breaking change and you should upgrade the major version.

I didn't say "it doesn't make sense for executables". I said it makes sense for terminal projects on which nothing has a versioned dependency. This is usually (maybe always) executables, but not all executables fall under that heading.

edit: Oh I see. I can see how you'd interpret what I said as implying that [all not libraries] are terminal. I wasn't being exhaustive. :)

Microsoft learned the hard way what it means not to enforce versions, hence why .NET also forces versioning at the dynamic loader level.

Java build tools are also built on top of versioning.

Isn't cargo a tool for sharing code?

If you share code you should use semver, because someone will (hopefully) import it and use it, and it communicates your expectations of stability.

Are you saying one can't write a Rust program that is just a simple, unversioned OS native executable without any Rust-this attached, or being embroiled in Rust-that?

You absolutely can. Cargo is not strictly speaking required to build Rust code, it just makes it so easy virtually everyone uses it.

rustc won't ask you anything about version numbers.

Yes. To be clear, I am not saying you can't do anything without cargo, but if you depend on any crates it makes very little sense to try to not use it. It only really makes sense to try if you have no external rust dependencies, which I think usually either means you're writing a kernel or a toy.

I actually use Cargo in my kernel, with dependencies like https://crates.io/crates/x86

So that just leaves toys :)

Fair enough. :)

Also, btw, even though I'm saying something vaguely negative about cargo I love that both rust and cargo exist and I've been aware of the work you've been doing since your rails days and always liked what you've done and had to say. Just thought I may as well throw that out there. :)

No worries! <3

I didn't even take it as negative, to be honest.

Reply on news.ycombinator.com