Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

SemVer has failed us

jongleberry.com

Post reply on HN
Print view View original

21–30 of 52 posts

Re: SemVer has failed us

#21

Post by StefanKarpinski »

Trombone5 wrote: post #20
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…

The argument in the article seems strange to me: "downstream relied on undocumented behavior, and now that behavior has changed, so downstream breaks" So what should upstream do? After all, the premise must be that the upstream does not control or even know about all the clients! The entire point is to separate the concerns, so how could upstream know if a bug fix is a breaking change if it passes the internal regres…

People rely on undocumented behavior all the time. In fact, most projects would be unusable if you didn't – it's a rare project that's perfectly documented. You're not going to hear from most of your users when you break stuff for them – most of them will just be silently annoyed. Enough annoyance from enough people and your library/language/whatever develops a bad reputation.

Re: SemVer has failed us

#22

Post by mattdesl »

npm init should really use 1.0.0 as default, and I agree 0.x.x should be dropped. It causes a lot of problems since most people publishing packages don't know what 0.x.x means, and they just end up leaving their (stable) modules at 0.0.0.

Re: SemVer has failed us

#23

Post by wycats »

AaronFriel wrote: post #16
arohner wrote: post #5

Completely agree. For a long time, I've thought that humans shouldn't be in charge of version numbers at all. The main problem is that a human isn't reliable at determining "is this change breaking?". Unfortunately our software isn't well-specified enough to allow the computer to determine version numbers automatically yet. To make this a reality, you'd need Haskell-level type safety, along with specifying other cons…

For anyone in the Haskell world, it's obvious that semantic versioning[1] doesn't work. Some non-trivial amount of that is likely due to how horribly broken Cabal is, a problem the community remains in staunch denial of. But for the rest, one problem is that because Haskell more thoroughly specifies types, individual functions can remain the same in behavior but change in type because a bug-fix, say, fixes a record t…

How would you say that Cabal is horribly broken?

Re: SemVer has failed us

#24

Post by bhaak »

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?

Re: SemVer has failed us

#25

Post by nardi »

His new versioning scheme ("ferver") is built on the premise that "people don't like it when major versions change often." Seems like a fourth version number is the solution, not breaking the semantics of SemVer.

I propose 4Ver. Just add a marketing version to the beginning. Update that one whenever you want (may include breaking changes). Since you have 4 numbers, you can remove the exceptions for the 0th version as well, and make version 0 follow the same rules as everything else. This cleanly separates the marketing/naming aspect of versions from the semantic aspects.

Re: SemVer has failed us

#26

Post by jongleberry »

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

Re: SemVer has failed us

#27

Post by jongleberry »

nardi wrote: post #25

His new versioning scheme ("ferver") is built on the premise that "people don't like it when major versions change often." Seems like a fourth version number is the solution, not breaking the semantics of SemVer. I propose 4Ver. Just add a marketing version to the beginning. Update that one whenever you want (may include breaking changes). Since you have 4 numbers, you can remove the exceptions for the 0th version as…

Could still be just 3. ..

Re: SemVer has failed us

#28

Post by nilved »

Versioning schemes like semver don't work in practice because change is breaking by definition. I'm increasingly convinced that the only version people should use is "latest." Security patches are the only things that should be retroactively added (maybe even as out-of-band patchfiles clearly marked with "to be used only until you get up and upgrade your software.") If you've amassed such tech debt that an upgrade is infeasible, you've forked the software and are responsible for its upgrades.

Re: SemVer has failed us

#29

Post by wycats »

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?

Node?

Re: SemVer has failed us

#30

Post by cwyers »

nmjohn wrote: post #7
angersock wrote: post #2

Semver hasn't failed anyone--web developers and the bozos in the Node community (of which I cheerfully count myself as a member) are lacking in discipline. You should be fast to get to 1.x.x. If your app breaks on a patch release (that was only a bugfix and provided that interfaces stayed consistent), maybe you shouldn't rely on buggy behavior and maybe you should fix your code. This isn't a failing of semver--this i…

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 things the way that's most convenient for package managers is just a little bit silly, no? Package managers are there to serve us, not the other way around. So maybe instead of "fixing" version numbers so that they're the most convenient for package managers, maybe we can fix package managers so that they use something better suited to handling dependencies than version numbers, so that we can use version numbers to communicate with people, not just package managers.

Post reply on HN