Hacker News Reader

Comment by exacube | Hacker News Reader

I think for a package versioning system to work, the ecosystem has to adhere to its principles. This is true for any package system.

I think this post is an example of a package not adhereing to its principle; a major revision implies breaking changes, so it doesn't make sense to have a tool "automatically update" things for you, because theres no garuntee that it'll work.

I feel like the issue is that this post doesn't totally understand how the package versioning is meant to work in the first place; if you're changing your struct names and it has no external effects, i don't see why you /want/ to semver, because you're exactly getting much value from semver'ing other than the vanity of pretty numbers. Maybe I'm missing something?

Im curious if an ideal package system that would work for this particular project, but I don't think one does.

View on HN

Exactly this.

The whole point of semver is to address the issue of backward-incompatible changes breaking downstream dependencies (well, among important other things).

What Go is doing is forcing you to use Semver the way it is intended to be used; from the semver specification:

---

Given a version number MAJOR.MINOR.PATCH, increment the:

    MAJOR version when you make incompatible API changes,
    MINOR version when you add functionality in a backwards compatible manner, and
    PATCH version when you make backwards compatible bug fixes.

Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.

---

If you don't want to adhere to this, just cut PATCH versions and MINOR versions.

It's an absolute terrible idea though.

As annoying as it may seem, there's a lot of benefits to using semver the way it is intended to: it forces you, the developer, to think a little more about how you design your code.

The small amount of productivity you lose getting used to do the proper thing (i.e. cut MAJOR version, or spend more time designing your code so that it more forward thinking) will pay off in the long term.

The tiny amount of productivity you gain by not doing the right thing will come back to haunt you and make you wish you had been more rigorous.

His startup might be small right now, but if it becomes successful, their number of internal users might explode overnight and they'll suddenly wish they had used semver properly all along.

Personally, there is no "too small for semver". Feels like every time I've done the lazy thing and failed to bump a major, even if it's small package Foo written only by me used in Bar, also only by me, there comes a time a few weeks later of digging through to figure out what broke.

When you are crunching for a deadline, the last thing you want is "oops the tool automatically bumped all the major versions on you" when you didn't explicitly intend to. Having a dedicated flag would be nicer than grep/sed though.

Go is not forcing you to use semver the way it's meant to be used. Go is adding constraints to package naming and versioning above and beyond what semver requires.

How does semver handle the case where I have v2.x.y and I want to change the API but I need to experiment for a few releases?

I want to get to a v3.x.y but I need. a bunch of pre-3 major versions first. Linux kernel used to do with odd numbers for experimental versions and even numbers for stable versions.

You're confusing "it should be easy to stay in the lines" with "it should be very cumbersome to draw outside the lines".

Its trivial to bump versions in countless package managers but its frustrating in Go. Telling this dev that he's holding it wrong seems like undue push back. Why should this be cumbersome? I don't think accidentally taking major versions is a problem in most package managers.

It's bad to design the language to make it convenient for newbies in a way that makes it painful forever once you've written a nontrivial amount of code. Put newbie hacks in a playground where they belong.

The one criticism that seems valid to me is that the tooling should tell you if there is a new major version available (while not updating for you)

I am not a Go user, but if it is truly the case that you get no notification when a new major version is available, that could be annoying.

> The one criticism that seems valid to me is that the tooling should tell you if there is a new major version available (while not updating for you)

Only if the older major version is deprecated. I do not want to be annoyed with the existence of new major versions unless I have to. My code already works with the older version.

The older major versions are likely not getting bug fixes, and might not get security patches if they are old enough.

Reply on news.ycombinator.com