Item — HN Reader

I've run into that too. People attach a lot of value to version numbers, even for internal projects/releases, and it's hard to get their perspective shifted to just accept it as communication tool (e.g. semver).

There's nothing special about 1.0.0 vs 2.0.0, it just means there was a breaking change and you may need to do some work when upgrading.

And a major, awesome feature might get released as 1.15.25 -> 1.16.0, that's OK. (marketing hates this)

2 comments

Just make everybody happy by using MARKETING.BREAKING.FEATURE.BUGFIX versioning, and then personally ignore the leading number (since it is actually meaningless). Or just have a separate marketing version. I'm not even (just) joking. Notice that this is not unlike Windows (Windows 7 through 8.1 were NT 6.1 - 6.3, then 10 went crazy even on internal versioning) or Solaris (which made it from version 2 to 11 on internal version 5.x).

This is essentially my plan for releases of the finl app. It'll have a three-part semantic version number (which I suspect will be 1.x.y forever) and then a “marketing” name indicating the major feature checkpoints, for which I'm going to name releases by element.¹ I figure I'll be dead long before I ever hit Ununennium and if anyone still uses finl by that time it will be someone else's problem.

⸻⸻⸻

1. It would be nice to have some mathematical theme, but I don't know of anything that's (a) sufficiently well-known (going with, say, famous mathematicians wouldn't work because the list is not necessarily agreed upon nor is it obvious to the casual user whether Riemann comes before or after Weierstrass), (2) non-numeric (so no fibonaccis or primes) and (iii) of sufficient length (so no platonic solids or named polygons).

SemVer is best IMO. Though I can see why it's hard to define exactly what constitutes a breaking--therefore major version--change when talking about user visible products or services.

Which version of semver are you talking about?

Personally I'm frequently rug pulled by breaking changes in patch updates.

Imo, semver is just a way for lazy devs to break backwards compat and feel ok about it.

Which would be fine if they maintained their old versions, which of course they don't, so what's the point of semver? All the breaking change version change means to me is you've forked your library and left me holding the bag.

I either have to update my code to accommodate your changes or I need to change your code to accommodate security issues.

And fuck me sideways if I have you as a peer dependency.

Do you think SemVer is really the root cause? Or would those devs have broken compatibility anyway, just without bumping the major version?

Is there a better alternative?

Again, which version of semver are you talking about?

And yes, of course they would have, but at least they wouldn't be able to lie about what theyre doing.

There is a better alternative, maintain backwards compatibility. And if you break it, acknowledge what you're doing, forking your lib and leaving everyone who relied on you holding the bag.

Linux has maintained backwards compat for decades, there really isn't much excuse.

> Linux has maintained backwards compat for decades, there really isn't much excuse.

In what way? IIRC there is no stable ABI in Linux.

Regardless maintaining backward compatibility forever is non-trivial. Besides Java I can't think of another major platform still actively supporting their v1.0 work.

Syscalls are the stable ABI in Linux.

ComVer is much-much better: https://gitlab.com/staltz/comver