Scala major version incompatibilities

Scala major version incompatibilities broke some of the most basic expectations I had out of a language and ecosystem. Being from Java world, backward compatibility had become a fact of life not to be given a second thought.

If I have built a class using JDK 5, I do not have to worry about bytecode compatibility when running with or consuming it from a piece of code I am compiling with JDK 7.

Whereas in Scala, code compiled in Scala 2.8 cannot be consumed in Scala 2.9 or 2.10. It has to be compiled all over again.

This is a major hurdle for the scala platform in being enterprise ready.

Here is a quote from David Pollak, the creator of Lift.

As traits change, the classes that depend on those traits “break” unless they are recompiled.  This means that as Scala grows and evolves, all the libraries that sit on top of Scala must be recompiled against the latest version of Scala.  This has presented a significant challenge as Scala 2.8 has evolved.  Each of the layers necessary to compile libraries (e.g., Scala -> ScalaCheck -> ScalaTest -> Specs -> Lift) must be compiled against the same version of Scala.  Because of this issue, it’s been challenging to keep the growing number of Scala libraries up to date with Scala 2.8.

What did he do? he started a community initiative called “Fresh scala”. He talks about impact of version fragility problems and why he started the community here

Since then,  ”Scala guys at typesafe” took notice and have been investing in solving these problems. For example, they have introduced a “Cross compilation” feature within SBT builds. Well, It is a start!

Major version incompatibilities is a factor large enough to shape the Scala communities efforts and ecosystem as a whole.