SemVer has failed us • Hacker News Board

Re: SemVer has failed us

#31

Post by jpollock » Fri, Aug 08, 2014, 10:02 PM UTC

The bigger problem has always been when the version number is marketing.

I worked in one team, and there was a contractual requirement that v 1.16 was the last version we would ship. So, where before we would increase the number at certain steps, we stopped at 1.16 and shifted to a third digit. Since we were a continuous build shop, we ended up with 1.16.110 very quickly. At that point, we shifted from 3 digit versions to a version number which was marketing controlled and a build number which was controlled by engineering (hashed from the tag+date).

This pattern repeated over and over. The version number would be communicated to the customer, a new version would be needed and so the version number would grow a digit. It ended up at X.Y.Z.A.B rev C. Yes, it was silly.

So, no matter what you use, make sure you keep your externally visible version numbers separate from the numbers you use to talk about them internally. :) Internal numbers should remain completely opaque to the customer.

Re: SemVer has failed us

#32

Post by papaf » Fri, Aug 08, 2014, 10:02 PM UTC

bhaak wrote: post #24

dustingetz wrote: post #10

Semver is busted because it makes builds non-deterministic. Building the same code tomorrow may fail if a third party dependency publishes a change violating semver. For example: https://github.com/bower/bower/issues/1404#issuecomment-4876... I unfortunately can only complain, I have no solution to offer.

Huh? Which ecosystem advocates automatic updates and doesn't allow locking the version numbers of the dependencies until a developer manually updates them?

I think that Go does not lock the version numbers by default. However, you have to sync manually - its not like Maven that attempts to download the internet on every build.

Re: SemVer has failed us

#33

Post by StefanKarpinski » Fri, Aug 08, 2014, 10:02 PM UTC

jongleberry wrote: post #26

StefanKarpinski wrote: post #8

We've used SemVer for Julia for a while now and it seems fine. However, versioning and compatibility are still hard problems and a perennial, unavoidable pain. The way I like to think of it is this: - patch: forwards and backwards compatible – only bug fixes, no new features, no changing existing features. - minor: backwards compatible – new features allowed, but old code should keep working. - major: all bets are of…

Any suggestions for improving the spec? I wrote that in like an hour and I have no experience writing specs. I don't and wouldn't even really use it anyways. Easier to just follow semver and bump minor instead of patch if there's a remote possibility of anything breaking

I think it would make more sense to try to clear up the parts of SemVer that remain unclear. You are quite right that the areas that require the most judgment and thus cause the most problems are pre-1.0 and patch releases. I think that specifying that pre-1.0 minor releases are like major releases while patch release are the same would clear things right up.

Regarding patch releases, the only thing that has "absolutely no chance of breaking anything" is no change at all – keeping the exact same version. Deciding what constitutes a patch-release bug fix is a matter of exercising good judgement about what won't (reasonably) break people's code. That could definitely be clarified in the SemVer spec. Asking yourself "is there a chance that this change might screw someone over?" and if so, how crazy was what they were doing?

Re: SemVer has failed us

#34

Post by jahewson » Fri, Aug 08, 2014, 10:10 PM UTC

malandrew wrote: post #18

Personally, I would far prefer a strong contracts system over semantic versioning. The ability to say "I rely on these N interfaces to present accept these argument types and return these types, and here are some test arguments and the values I expect returned" to be a much better way of describing what you rely on. Even better is that by defining things in terms of contracts, you should be able to replace dependenci…

Unless you checked every possible result for every possible function call you use then the 3rd party library could have been changed in such a way which would break your program. There's no way to prevent such situation in general, e.g when the input value space is non-finite.

Other kinds of specification would seem very hard to test, for example rendering a 3D scene, if we used a bitmap as test data then we'd get false positives when the rendering is improved in some minor way, and the spec will fail, we'd need to use some perceptual metric for image similarity instead.

Version numbers aren't so bad, given their ease of use.

Re: SemVer has failed us

#35

Post by nmjohn » Fri, Aug 08, 2014, 10:10 PM UTC

cwyers wrote: post #30

nmjohn wrote: post #7

Earlier quoted context omitted.

I don't disagree, but unfortunately believing that humans - no matter how logical CS people tend to be - will always think completely logical and rational is a flawed line of thinking. Yes, people _should_ get over changes in version number, but in reality they don't. So library authors cater to reality, not how they wish things should be. That is the problem, and why semvar is broken. Not in principle it isn't, but…

Well, people use version number to communicate a lot of things that aren't captured by the strict, rigid form of semver. And when you follow semver, you omit communication about all of those other things. Now, if you think that the only things worth caring about are what semver says matters, then you don't view this as important. But there's a lot more to the world than package managers, and expecting people to do th…

I should have added a conclusion to my post but I sometimes feel they don't always further technical discussions because once a conclusion is applied, dissenters tend to ignore the logic leading up to it no matter how valid.

But I do agree that package managers are there to serve us, not the other way around. The unfortunate thing is this issue is one of differences in human nature and how a given person prefers their system to be - rigid and concrete maximizing efficiency; or fluid and communicative adding overhead but increasing understandability.

Re: SemVer has failed us

#36

Post by thedaniel » Fri, Aug 08, 2014, 10:14 PM UTC

I want to agree with the sentiment about the human side of versioning being unreliable, but when the author "pins" the argument on the fact that pinning all versions is "annoying" s/he loses me. Pinning (and vendoring) everything is the only way to know that exactly what you expect to be deployed will be deployed when you deploy it. Anything less is inappropriate for production environments.

Re: SemVer has failed us

#37

Post by jongleberry » Fri, Aug 08, 2014, 10:19 PM UTC

thedaniel wrote: post #36

I want to agree with the sentiment about the human side of versioning being unreliable, but when the author "pins" the argument on the fact that pinning all versions is "annoying" s/he loses me. Pinning (and vendoring) everything is the only way to know that exactly what you expect to be deployed will be deployed when you deploy it. Anything less is inappropriate for production environments.

You're assuming that development and production version ranges will always be the same, which is false. This is what npm shrinkwrap is for, and not pinning during production is stupid. But pinning everything in development is unnecessary until you stage/deploy.

Re: SemVer has failed us

#38

Post by 33a » Fri, Aug 08, 2014, 10:20 PM UTC

SemVer isn't broken, and you already outlined the obvious solution:

1. Don't depend on 0.x.x version modules unless you are willing to accept the pain of updating versions constantly.

2. Bump major versions liberally.

If enough people just get used to this reality, then everything will be fine. The problem is trying to impose artificially conceived notions of how things "ought" to work on top of this.

Until someone invents a viable system for checking invariants and interfaces on codes statically, semver is pretty much the only show in town for specifying compatibility between code modules.

Re: SemVer has failed us

#39

Post by jongleberry » Fri, Aug 08, 2014, 10:22 PM UTC

bcoates wrote: post #11

You had me until "Duplicate dependencies are bad". The reason every package manager except npm and Apple's bundles are a piece of shit is because they attempt to install random dependent garbage globally and by default.

You're assuming "no duplicate dependencies" is equivalent to "install globally", which is false. In the article's context, the argument is against duplicate dependencies per project

Re: SemVer has failed us

#40

Post by makomk » Fri, Aug 08, 2014, 10:42 PM UTC

StefanKarpinski wrote: post #8

We've used SemVer for Julia for a while now and it seems fine. However, versioning and compatibility are still hard problems and a perennial, unavoidable pain. The way I like to think of it is this: - patch: forwards and backwards compatible – only bug fixes, no new features, no changing existing features. - minor: backwards compatible – new features allowed, but old code should keep working. - major: all bets are of…

Worse still, people can - and do - rely on behaviours that cause major security holes. So not only are some fixes backwards compatible for most but not all users, it can be critically important that those users get the version with the fix and not an older unpatched version.