Hacker News Reader

Comment by allo37 | Hacker News Reader

I feel like this is meant to be satire, but I wonder if there's some truth to it: Usually updates to a "major" version come with an implied assumption that there won't be any breaking API changes.

Maybe being perpetually at 0 gives you the "It's beta software, you need to update bro" defence against maintaining a stable API, and all the extra overhead that comes with it.

View on HN

There won't be any breaking API change until the next major version. Nothing in semvet prevents you from having releases 1, 2, 3, 4 instead of 0.1, 0.2, 0.3, 0.4. At some point you can just drop the zero and carry on, it's false to say that you can't make breaking changes after 1.0.

I feel like this is meant to be satire, but I wonder if there's some truth to it

Yes and yes. But isn’t that kind of the point of good satire?

Yes. From my perspective one benefit of 0 major version in 1-person OSS projects is it gives a clear signal that "yes this code is available for you, but no I'm not an enterprise support solution, I'll do what seems useful/relevant to me when I have time and when it feels relevant".

That doesn't mean intentionally breaking backwards compatibility but also this isn't my paid day job so I might do it and I'm not going to spend my evenings compiling release notes / migration guides for free.

In this way it's an effective anti-big-corp shield since a lot of enterprises have dumb rules about using beta/alpha versions. I think it's a strong signal where people can't just use a beta or pre-release version of some code that they're a) not auditing their dependencies and b) probably work somewhere that has the money to pay for that level of service but just want you to do it for free.

Why not release 2.x after a month, breaking the API again? Heck, why not next day when you find out that all APIs suck.

Because you'll still have customers on version 1.x, who will still expect support and refuse to update for <reasons>. It's not that it's impossible but it imposes an additional burden on the development team, which affects how fast you can add features.

That's why our team at GigaCorp has switched to not using minor version numbers. In the past we had customers who expected continuous security updates without updates to the minor version due to some internal policy. All of our new products use 0.0.x versioning where x is incremented for each release. This way we can easily push out new releases and our customers have no reason to delay updates.

But that's the same with 0.1 and 0.2. You will still have users in 0.1 who will expect support and refuse to update.

Unfortunately irrationally difficult customers are a bit like death and taxes in that sense, but "We have a new version with some minor fixes that you can use" is generally an easier sell than "We have a new version with some major changes that will completely disrupt your workflow".

This is true no matter what you name your versions, I don't know what you are saying.

Reply on news.ycombinator.com