Comment by star-trek-fleet | Hacker News Reader

Comment by star-trek-fleet | Hacker News Reader

Parent Full thread

star-trek-fleet

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.

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.

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.

Reply on news.ycombinator.com