Scala 2.11.3 is dead on arrival

[Grzegorz Kossakowski]

Hi!

I've got an important information to share. I'd like to announce the Scala 2.11.3 artifacts as being dead on arrival. The 2.11.3 artifacts that got released to Maven Central have a critical bug related to binary compatibility. Please stick to using Scala 2.11.2 until 2.11.4 is released which is planned to happen as soon as we fix all critical bugs found in Scala 2.11.3. The rest of my email will discuss the events that led to a broken Scala release, next steps we're planning to take.

Why did broken release got published

We've received two critical bug reports for Scala 2.11.3 release. The first bug (SI-8899) is about broken binary compatibility of Scala's standard library. The second bug (SI-8900) is a compiler crash preventing a few projects from compiling.

The binary compatibility breakage is caused by a human mistake introduced by pull request #3949. That pull request disables our automatic binary compatibility checks for certain library classes. The pull request includes the reasoning why we thought this is safe to do. As is turned out, we were wrong in our judgement and the full explanation what went wrong can be found here.

The compiler crash got introduced by fixes in Scala compiler's backend. Check SI-8900 and linked pull requests for details.

I'd like to comment on why our automatic testing didn't catch those problems. The binary compatibility checking was disabled as a human error. Moreover, the community build doesn't help with testing binary compatibility because all projects are being recompiled from source. That's because we use the same config to test both 2.11.x and 2.12.x branches. The compiler crash would have been caught by community builds if the projects that crash the compiler have been included in the config. If you would like to help the Scala project, please have a look into adding more projects to community build. We need to distribute the work if we want to grow the list of projects we are testing Scala compiler against.

What are the next steps

We'll go through all reports we have received so far and determine the importance the issues. The two issues discussed above will be fixed and once we regain our confidence, we'll move forward with 2.11.4 release. In particular, the focus of 2.11.4 process is just to fix the critical issues that went into 2.11.3. Any other work will be postponed to 2.11.5 release.

We'll also look into some additional testing we can introduce that will prevent such problems to happen in the future.

I'd like to thank a several community members that tried Scala 2.11.3 even before it got officially announced and quickly reported the issues they found. This prevented the Scala 2.11.3 release from being officially announced and prevented from bigger damage to happen!

--
Grzegorz Kossakowski

Scalac hacker at Typesafe

twitter: @gkossakowski

github: @gkossakowski

[Hanns Holger Rutz]

On 10/14/2014 01:59 AM, Grzegorz Kossakowski wrote:
> The binary compatibility breakage is caused by a human mistake
> introduced by pull request #3949

> <https://github.com/scala/scala/pull/3949>. That pull request disables

> our automatic binary compatibility checks for certain library classes.

Classic. This is how Chernobyl happened. And UK just decided to build a
new reactor, because you know, human errors don't happen :-O

Sorry OT, .h.h.

[Hanns Holger Rutz]

On 10/14/2014 01:59 AM, Grzegorz Kossakowski wrote:

> Moreover, the community build
> <https://github.com/scala/community-builds> doesn't help with testing

> binary compatibility because all projects are being recompiled from
> source. That's because we use the same config to test both 2.11.x and
> 2.12.x branches.

[...]

> We'll also look into some additional testing we can introduce that will
> prevent such problems to happen in the future.

It's probably quite a bit of work, but wouldn't it be possible to run
the community build such that for each project it gets compiled against
dependencies that are themselves compiled against minimum compatible
version. E.g. project B uses library A. Project B is test:compile'd with
Scala 2.11.4, using library A that was compiled with 2.11.0. I don't
know if that would have triggered the problem in advance?

Best, .h.h.

[Jon Pretty]

On 14 Oct 2014 09:43, "Hanns Holger Rutz" <con...@sciss.de> wrote:
> Classic. This is how Chernobyl happened. And UK just decided to build a
> new reactor, because you know, human errors don't happen :-O

Marginally less OT: the consultation website for that nuclear reactor ran on Scala...

Jon

[Adriaan Moors]

Yes, that would be great! We're planning to make it possible to use a 2.11.x compiler for a community build and then run all the test suites against 2.11.x+1. (And vice versa.)

--
You received this message because you are subscribed to the Google Groups "scala-internals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-interna...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Jason Zaugg]

Actually, it will be stronger to also mix the build version. E.g. build Akka with 2.11.0 and build and test Play with 2.11.3. 

-jason

[Kazuhiro Sera]

Hi,

Running tests against next minor release sounds good. Actually we found SI-8899 while running our tests against 2.11.3.

https://github.com/skinny-framework/skinny-framework/issues/193

We're ready to contribute community-builds by running our test suites!

Thanks,

-Kaz