Does scala follow semantic versioning? It sounds like they should still be in the 0.x stage if there are enough breaking changes to merit this discussion
The deal is (I think) that Scala is a much quicker evolving language than say Ruby. Ruby 2.0 was rumored to be released the better part of a decade ago (anyone else remember Pickaxe 1.8, pre-Rails, saying that eventually parenthesis would no longer be optional in Ruby 2.0?).
Scala has developed new features at a pretty quick pace. By and large this doesn't mean breaking source compatibility. Most source seems to be forwards compatible, or require minimal effort.
The reason this comes up at all is because of Package Management. Where Ruby only needs to worry about a parser compatibility level, Scala has to worry about binary compatibility in packaging since it lives in Java's packaging ecosystem. Since Maven doesn't encode a binary version, breaking binary compatibility (say you added a new default argument to a method signature, that wouldn't otherwise break source compatibility, or you introduced a new superclass for a return value) means breaking your packages.
SBT gets around this by encoding the binary version (the Scala minor version) in the artifact name.
Some day this will all probably get sorted out.
It hasn't been much of a pain point for me personally. Most 3rd party binary packages are Java packages, which are binary compatible since Java 5(?). For the few Scala libs you might depend on, you might as likely be using a source dependency from Github, which means you don't need to worry since you're compiling it yourself, or most popular packages will have published versions with a new compiler pretty quickly.
The next time this will be an issue is when Scala 2.11.0 is released. And AFAIK that should introduce any breaking changes for source code at this point. So if you want to move to Scala 2.11.0 you either wait for package authors to cross-compile to it, or you build it yourself as a source dependency if you have access to the code.
major.minor.micro
Changes in .micro are assumed to be interchangeable. Scala does this.
Changes in .minor are assumed to be backwardly compatible, but with new features added. Scala does not do this, it requires a recompile.
Major versions indicate a completely incompatible change.
If Scala were to follow semantic versioning, it would need to coalesce the first two versions together and have e.g. 210 and 211 to indicate that they are not compatible with each other.
Which depending on your background may mean everything or nothing at all I guess.
Most Ruby libs would claim to follow semantic versioning. I think it's also fair to say there are a lot more mis-steps with compatibility on that side of the fence but I've not seen this argument used there that I can recall.
I mean, to be fair, your argument was "large enterprises". Which, means Java. And in that regard you're not wrong since binary compatibility there is a given.
Still... As long as you can clone and build the source (it's not like you're buying licenses for UI binary libraries built in Scala after all) I fail to understand why this is a bigger deal than say: String interpolation. Partial Functions. Function Lifting. Type Inference. Type Classes. Tuples. Pattern Matching. The list just goes on and on...
The question isn't "Is Scala ready to be the basis for closed source, licensed libraries" after all? If it were then a "we must maintain a decade of binary compatibility" might have a point. Otherwise it feels like a really hollow criticism. I mean, what actual Scala users out there actually want to see Scala 2.11's features put to death on the altar of binary compatibility?
Exactly, and that's what Scala is up against. Java 8 will allow Java 7 compiled libraries to run without changes, and though there's a world of difference between Java 8 and Scala, in practice Java 8 gives developers some new features that they'll find useful and more performant than Scala (parallel collections, no implicit casting/conversions etc.)
It's also worth noting that 'backwardly compatible' and 'new features' aren't in conflict with each other. Java has had new features added (invokedynamic at the JVM, try-with-resources and string switch in the language layer) but they've still remained binary compatible. The problem is that Scala's approach to new features is to break binary compatibility between 2.x and 2.x+1 releases.
This isn't quite true. I have a library (Breeze) that works with 2.10.3 but not 2.10.2. Something in name mangling changed, I think.
This article is actually filled with a bunch of mis-information about Scala version compatiblity. For example, the author states:
> There has never been a Scala release where it’s been possible to compile and run an older library with a newer version of a program.
This is not true at all. There are multiple libraries that support several binary incompatible versions of Scala from the same codebase. Also, as mentioned previously, there are multiple releases of Scala that are binary compatible with each other.
You can take a library compiled with Java 1.4 and have it run with Java 7.
That's the key point that is made here. The fact that version compatibility at the patch level is laughable; that should have been the default, not an additional selling point later.
The problem is that it's impossible to create a library (like log4j) and then make it available/support it across different versions. Each time you need to release a build, you have to build different versions - one for 2.9, one for 2.10 - in order to work.
At some point that breaks down; one key library in your chain no longer compiles on 2.9, so you have to move everything to 2.10 to do further work. It's the transitive closure for all those libraries and their dependencies that will get you in the end.
However, while you may think that binary compatibility is 'laughable', to imply that there have been no improvements in this area is disingenuous. The presence of this compatibility contradicts the claims you made in the article.
You also gloss over source compatibility. Which, again, contradicts the claims you made in the article.
> Major version zero (0.y.z) is for initial development. Anything may change at any time. The public API should not be considered stable.
major version 0 was specifically designed for this use case
I mean, my major touchstone is Ruby-land, and over there there's nothing like it. Even point releases of libraries or the language itself can and will routinely break your code. I've never seen that happen with Scala. Not saying it definitively hasn't, but I certainly haven't experienced it, and that's not because I'm using less of Scala than I did of Ruby...
It feels like shifting the goal posts to say that binary compatibility should be a bigger factor in versioning (and it's already represented in the minor version) when you've already arguably got better stability guarantees than many of it's contemporaries.
Unless we really are limiting the conversation to Java. But how do you compete with "we never break compatibility at the cost of never evolving"?