Hacker News Reader

Comment by gaius | Hacker News Reader

everything will be (more or less) automatically compiled and published for both Scala 2.11 and 2.12

But, having to worry about minor version differences like this is a wholly unnecessary problem, and one that didn't really exist in the world that make comes from.

These days we build tools on top of tools to solve problems of our own making that just didn't exist 10 or 20 years ago. All the build tools, packaging tools, deployment tools, containers, blah blah blah. None of that crap is needed to deliver working software in the form of 1 statically linked binary + 1 text configuration file, which will suffice for any software in the world.

View on HN

> But, having to worry about minor version differences like this is a wholly unnecessary problem

2.11 and 2.12 are major Scala versions. Current minor version is 2.12.4

But having to worry about compatibility between minor versions is still bad.

People have come to expect that minor versions are interchangeable (modulo fixes for clear regressions and changes made in reaction to important outside events like major releases of Java).

The minor versions are interchangeable. An increase to the second number is a new (binary incompatible) major version occurring every 1-3 years.

It's unusual but not unique, see Python, Linux kernel, Postgres.

It's not unusual either, afaik rapidly increasing x in x.y.z was very unfashionable before initial Chrome release. Many java projects (e.g. older Apache Foundation projects: Apache POI, etc) still follow that versioning scheme, it kinda looks like semver, but there is no commitment to preserving compatibility on y changes.

> The minor versions are interchangeable.

They are not, at least in Scala. See 2.12.x.

> But having to worry about compatibility between minor versions is still bad.

It's also unavoidable.

In theory, either the people doing the minor version releases need to worry about it, make conservative changes, thoroughly test those changes against a large amount of code, etc. - or the people consuming the minor version releases need to worry about it and do much of the same thing. Either way, build tools that can handle compiler versioning is a win.

In practice, both the people doing the minor version releases and the the larger codebases consuming those minor version releases need to worry about it. "fixes for clear regressions and changes made in reaction to important outside events" is already a giant caveat that will lead to breakage at times, and even the best teams will occasionally fail to meet expectations.

I'm not sure what you are arguing against.

All I'm saying is that the situation is bad as-is, and it would be good to not make it any worse.

Reply on news.ycombinator.com