Hacker News Reader

Comment by eurasiantiger | Hacker News Reader

Shenanigans aside, 0.x versioning is commonly used when developers cannot (yet) make any guarantees about backwards compatibility between minor releases.

View on HN

At the risk of sucking the fun out of a pretty funny joke, I think the underlying subtext is that established projects are failing to "grow up" -- i.e., that established, depended-on projects are hiding under the shield shield of a youthful 0.x version, when really, given how popular, old, and depended-on they are, they should embrace that responsibility and grow into 1.something.

(Though, on the other hand, maybe it's more just honest signaling of expectations. "We are a 0.x project, we value developer speed and a clean code-base more than backcompat or stability for users. We will NEVER grow up!" We could call it Peter Pan versioning.)

I’d hazard a guess that many of those projects are for environments that cannot guarantee stability, so the instability kind of rolls over to the projects themselves.

I think they just don't care about marketing. 1.0 being grown up is a marketing perspective. You could start at 2.0 and not be "grown up" in the slightest.

This is an unhelpful argument. It effectively says "meaning doesn't exist". I could also version my software "chicken.banana.guacamole" and be pissed that nobody understood that meant it was enterprise-and-production-ready. Point is, there's a convention and this satire website is pointing out obviously-wrong cases of mis-versioning.

> It effectively says "meaning doesn't exist".

No.

It says that there's no universal agreement on this one thing, and while if you want to sell to certain people you should tailor your versioning appropriately, there's zero point in assuming a single interpretation. If I use CalVer some people who think there's only one way to do this may assume the product has had 2021 major version releases.

That would be a silly assumption.

"Peter Pan versioning"

This really should be the term for projects that are perpetually releasing 0.x versions.

Maintainers are free to release their software under whatever terms that they wish, but if you actively encourage people to use your software and do not want to maintain backwards compatibility, then IMO, you should be very honest about that.

Once a project has been out for years, and has thousands or millions of users, it's not in the experimental phase any more, regardless of what the version number claims.

Similarly to https://www.hyrumslaw.com

It has nothing to do with experimental status; rather, some efforts like React Native concern platforms that constantly introduce new OS versions with new and deprecated APIs. It doesn’t make sense to pin versions to device generations when there are half a dozen different vendors to account for: if changes to one platform mandate breaking changes, all platforms would be affected anyway, and any platform can change at any time. Since new devices are first adopted by people with lots of money, developers have an incentive to stay as current as possible, so the point of pinning to device versions or generations is completely moot.

In semver terms that means increasing semver-major. Instead of 0.x.y you do x.y.z. There's no rule in semver that says you need to stay on 1.x forever.

It’s just that version 724.1.2 might look weird in some eyes.

Reply on news.ycombinator.com