Hacker News Reader

Comment by couchand | Hacker News Reader

The benefits are actually much deeper though. Now that we know exactly how the API has changed, it is possible to automatically enforce strict versioning rules. If there are breaking changes, the new release must be a major version bump.

This is very interesting to me. It demands consideration: do we need a person to manually bump the version anymore at all? If you can statically verify that a change meets the criteria, couldn't the package publishing process autoincrement the appropriate version segment and be done with it?

View on HN

there are probably cases in which you want to change the version independently of API changes, i.e. "going stable" (0.x to 1.0), major internal changes, new interfaces with deprecations of the old ones etc.

Good point, you still need an escape hatch to bump a version segment higher than the minimum necessary one, for many reasons.

I'm not sure I agree that the phrase "going stable" really applies to a semver project. The most stable release would just be the highest number in each segment. Version 1.0.1 is almost by definition going to be more stable than 1.0.0, since the changes are only backwards-compatible bug fixes. At least that's my understanding of semver.

semver has a special case for 0.x, which is basically "before 1.0 there are no guarantees". In their words:

> Major version zero (0.y.z) is for initial development. Anything may change at any time. The public API should not be considered stable.

(Yes, this means that you can use 0.x and declare yourself "semver compatible" and break on any patch release)

It seems doable to differentiate additions from (breaking) changes if all the API is statically defined. It would be nice to even have the feedback on larger changes.

That being said it's possible to change a library's behaviour without touching the API. Consider the following diff:

    -add a b = a + b
    +add a b = a - b

Granted the example is simplistic. With the API versioning system in place the author should have renamed the method and would have gotten the right result. It's just to show that it wouldn't be a silver bullet.

My attitude towards developer tooling tends to be: build the tools first for the experts, and second make sure the are learnable. I can't stand professional tools that are built primarily for new users. Englebart's violin [0] and all that.

That said, it might be the case that removing the responsibility of versioning from experts would make them less concerned about the ramifications, and less likely to notice when they make a change like this one (well not this one exactly, but one similar but more reasonable).

You really do need tests in addition to static analysis to be sure of these things.

[0]: http://www.loper-os.org/?p=861

I think it has as much to do with standardization as ease of use. This way, if there are multiple experts, they don't each do it their own way.

Plus, it gives a degree of reliability to those using the packages, which is something you can't necessarily count on in Haskell right now.

Reply on news.ycombinator.com