Hacker News Reader

Comment by henvic | Hacker News Reader

I recognize that this might be a PITA, but for me there is no easy way out of problems related to major versioning, and the clear answer is sticking with version 0.x.x for a considerate amount of time.

It seems people rush to publish version 1.0 (or 2.0, etc.) of their libraries, when they'd be better off just sticking with version 0.x.

It's not like that a package isn't ready for production because it is < 1.0. It might as well be. If you're an early adopter, I'd say that is even welcome: you're aware that its API might chance, that its quite new, etc. It gives more confidence than a package with version 7.x (at least in informing you that it's prone to changes, and allowing you to make an informed choice), IMHO.

View on HN

Lots of teams, companies, and general best practice all have policies and/or guidelines around versioning, and its usually something to the effect of wait till the package is 1.0 to use it in production. I think that's why there is always a "race" to the 1.0

I think we should just push for more date based versioning, for instance, CalVer[0]

[0]: https://calver.org/

All of my Go packages are CalVer v0.year.increment because I'm just a lone developer, so nothing I release can be v1. To be an actual v1, there needs to be a team of people who are committed to keeping a package going indefinitely. I understand why people want to use v1, because it sounds cool and stable, but realistically if you are just releasing code on your own, it is not and cannot be v1.

Why would a package released as v1 need to be supported indefinitely?

Because v1 is a social commitment to keeping the API stable and the library working for the foreseeable future. If you don’t want to make that commitment, there’s always v0, which I do in fact use.

Semantic versioning serves a purpose - it makes it possible to automatically update dependencies to the latest compatible version without breaking code.

If you don't need automatic updates, then any kind of versioning is fine. Hell, you could get away with just using a single incrementing integer. v1, v2, v3, ..., v225883, etc.

That's a terrible purpose, and SemVer does no such thing. There are approximately 0 large libraries that actually offer SemVer style guarantees. For example, the Go stdlib itself is definitely not using SemVer, as it often introduces breaking changes between minor versions.

The only thing loose dependencies and automatic version resolution and duplicating libraries achieve is a false sense of security when upgrading code. And the only thing Go's awful, awful idea to force v2+ to change import path is to make a mess in your version control history, and hide the important bits in a sea of needlessly changed files.

Semver isn't designed for this, and this whole idea of automatically updating dependencies is awful. Don't do it. Use discretion when updating anything.

Large-scale compatibility is exactly what semver was designed for.

> this whole idea of automatically updating dependencies is awful.

Yeah, well, that's just, like, your opinion, man.

You may be entertained by WarpVer: https://gist.github.com/warpfork/98d2f4060c68a565e8ad18ea481...

It's not SemVer(tm).

That's it. That's the whole pitch.

There's also a section specific to golang, which indeed advocates for sticking with version 0.x.x for a very long time: https://gist.github.com/warpfork/98d2f4060c68a565e8ad18ea481...

Reply on news.ycombinator.com