The last time Hackerfall tried to access this page, it returned a not found error. A cached version of the page is below, or clickhereto continue anyway

Scala 2.11.0-RC1 is now available! | The Scala Programming Language

March 6, 2014

We are very pleased to announce the first release candidate of Scala 2.11.0! Download it now from scala-lang.org or via Maven Central.

Please do try out this release candidate to help us find any serious regressions before the final release. The next release candidate will be cut on Monday March 17, if there are no unresolved blocker bugs at noon (PST). Subsequent RCs will be released on a weekly schedule, with Monday at noon (PST) being the cut-off for blocker bug reports. Our goal is to have no more than three RCs for this release please help us achieve this by testing your project soon!

Code that compiled on 2.10.x without deprecation warnings should compile on 2.11.x (we do no guarantee this for experimental APIs, such as reflection). If not, please file a regression. We are working with the community to ensure availability of the core projects of the Scala 2.11.x eco-system, please see below for a list. This release is not binary compatible with the 2.10.x series, to allow us to keep improving the Scala standard library.

For production use, we recommend the latest stable release, 2.10.3 (2.10.4 final coming soon).

The Scala 2.11.x series targets Java 6, with (evolving) experimental support for Java 8. In 2.11.0, Java 8 support is mostly limited to reading Java 8 bytecode and parsing Java 8 source. Stay tuned for more complete (experimental) Java 8 support.

The Scala team and contributors fixed 544 bugs that are exclusive to Scala 2.11.0-RC1! We also backported as many as possible. With the release of 2.11, 2.10 backports will be dialed back.

Since the last milestone, we fixed 133 issues via 154 merged pull requests.

A big thank you to everyone whos helped improve Scala by reporting bugs, improving our documentation, participating in mailing lists and other public fora, and of course submitting and reviewing pull requests! You are all awesome.

Concretely, between Jan 2013 and today, 69 contributors have helped improve Scala!

Our gratitude goes to @paulp, @som-snytt, @soc, @JamesIry, @Ichoran, @vigdorchik, @kzys, @Blaisorblade, @rjolly, @gourlaysama, @xuwei-k, @sschaef, @rklaehn, @lexspoon, @folone, @qerub, @etaty, @ViniciusMiana, @ScrapCodes, @pavelpavlov, @jedesah, @ihji, @harrah, @aztek, @clhodapp, @vy, @eed3si9n, @mergeconflict, @greenrd, @rjfwhite, @danielhopkins, @khernyo, @u-abramchuk, @mt2309, @ivmaykov, @yllan, @jrudolph, @jannic, @non, @dcsobral, @chuvoks, @rtyley.

With special thanks to the team at EPFL: @xeno-by, @densh, @magarciaEPFL, @VladimirNik, @lrytz, @VladUreche, @heathermiller, @sjrd, @hubertp, @OlivierBlanvillain, @namin, @cvogt, @vjovanov.

If you find any errors or omissions in these relates notes, please submit a PR!

Reporting Bugs / Known Issues

Please file any bugs you encounter. If youre unsure whether something is a bug, please contact the scala-user mailing list.

Before reporting a bug, please have a look at these known issues.

Scala IDE for Eclipse

The Scala IDE with this release built in is available from this update site for Eclipse 4.2/4.3 (Juno/Kepler). Please have a look at the getting started guide for more info.

Available projects

The following Scala projects have already been released against 2.11.0-RC1! Wed love to include yours in this list as soon as its available please submit a PR to update these release notes.

"org.scalacheck"    %% "scalacheck"         % "1.11.3"
"org.scalafx"       %% "scalafx"            % "1.0.0-R8"
"org.scalatest"     %% "scalatest"          % "2.1.0"
"org.specs2"        %% "specs2"             % "2.3.9"
"com.typesafe.akka" %% "akka-actor"         % "2.3.0-RC4"
"org.scalaz"        %% "scalaz-core"        % "7.0.6"
"com.nocandysw"     %% "platform-executing" % "0.5.0"

NOTE: RC1 ships with akka-actor 2.3.0-RC4 (the final is out now, but wasnt yet available when RC1 was cut). The next Scala 2.11 RC will ship with akka-actor 2.3.0 final.

Cross-building with sbt 0.13

When cross-building between Scala versions, you often need to vary the versions of your dependencies. In particular, the new scala modules (such as scala-xml) are no longer included in scala-library, so youll have to add an explicit dependency on it to use Scalas xml support.

Heres how we recommend handling this in sbt 0.13. For the full build, see [@gkossakowskis](https://github.com/gkossakowskis) example.

scalaVersion        := "2.11.0-RC1"

crossScalaVersions  := Seq("2.11.0-RC1", "2.10.3")

// add scala-xml dependency when needed (for Scala 2.11 and newer)
// this mechanism supports cross-version publishing
libraryDependencies := {
  CrossVersion.partialVersion(scalaVersion.value) match {
    case Some((2, scalaMajor)) if scalaMajor >= 11 =>
      libraryDependencies.value :+ "org.scala-lang.modules" %% "scala-xml" % "1.0.0"
    case _ =>
      libraryDependencies.value
  }
}

Important changes

For most cases, code that compiled under 2.10.x without deprecation warnings should not be affected. Weve verified this by compiling a sizeable number of open source projects.

Changes to the reflection API may cause breakages, but these breakages can be easily fixed in a manner that is source-compatible with Scala 2.10.x. Follow our reflection/macro changelog for detailed instructions.

Weve decided to fix the following more obscure deviations from specified behavior without deprecating them first.

The following changes were made after a deprecation cycle (Thank you, @soc, for leading the deprecation effort!)

Finally, some notable improvements and bug fixes:

To catch future changes like this early, you can run the compiler under -Xfuture, which makes it behave like the next major version, where possible, to alert you to upcoming breaking changes.

Deprecations

Deprecation is essential to two of the 2.11.x series three themes (faster/smaller/stabler). They make the language and the libraries smaller, and thus easier to use and maintain, which ultimately improves stability. We are very proud of Scalas first decade, which brought us to where we are, and we are actively working on minimizing the downsides of this legacy, as exemplified by 2.11.xs focus on deprecation, modularization and infrastructure work.

The following language warts have been deprecated:

Wed like to emphasize the following library deprecations:

Deprecation is closely linked to source and binary compatibility. We say two versions are source compatible when they compile the same programs with the same results. Deprecation requires qualifying this statement: assuming there are no deprecation warnings. This is what allows us to evolve the Scala platform and keep it healthy. We move slowly to guarantee smooth upgrades, but we want to keep improving as well!

Binary Compatibility

When two versions of Scala are binary compatible, it is safe to compile your project on one Scala version and link against another Scala version at run time. Safe run-time linkage (only!) means that the JVM does not throw a (subclass of) LinkageError when executing your program in the mixed scenario, assuming that none arise when compiling and running on the same version of Scala. Concretely, this means you may have external dependencies on your run-time classpath that use a different version of Scala than the one youre compiling with, as long as theyre binary compatibile. In other words, separate compilation on different binary compatible versions does not introduce problems compared to compiling and running everything on the same version of Scala.

We check binary compatibility automatically with MiMa. We strive to maintain a similar invariant for the behavior (as opposed to just linkage) of the standard library, but this is not checked mechanically (Scala is not a proof assistant so this is out of reach for its type system).

Forwards and Back

We distinguish forwards and backwards compatibility (think of these as properties of a sequence of versions, not of an individual version). Maintaining backwards compatibility means code compiled on an older version will link with code compiled with newer ones. Forwards compatibility allows you to compile on new versions and run on older ones.

Thus, backwards compatibility precludes the removal of (non-private) methods, as older versions could call them, not knowing they would be removed, whereas forwards compatibility disallows adding new (non-private) methods, because newer programs may come to depend on them, which would prevent them from running on older versions (private methods are exempted here as well, as their definition and call sites must be in the same compilation unit).

These are strict constraints, but they have worked well for us in the Scala 2.10.x series. They didnt stop us from fixing 372 issues in the 2.10.x series post 2.10.0. The advantages are clear, so we will maintain this policy in the 2.11.x series, and are looking (but not yet commiting!) to extend it to include major versions in the future.

Concretely

Just like the 2.10.x series, we guarantee forwards and backwards compatibility of the "org.scala-lang" % "scala-library" % "2.11.x" and "org.scala-lang" % "scala-reflect" % "2.11.x" artifacts, except for anything under the scala.reflect.internal package, as scala-reflect is still experimental. We also strongly discourage relying on the stability of scala.concurrent.impl and scala.reflect.runtime, though we will only break compatibility for severe bugs here.

Note that we will only enforce backwards binary compatibility for the new modules (artifacts under the groupId org.scala-lang.modules). As they are opt-in, its less of a burden to require having the latest version on the classpath. (Without forward compatibility, the latest version of the artifact must be on the run-time classpath to avoid linkage errors.)

Finally, Scala 2.11.0 introduces scala-library-all to aggregate the modules that constitute a Scala release. Note that this means it does not provide forward binary compatibility, whereas the core scala-library artifact does. We consider the versions of the modules that "scala-library-all" % "2.11.x" depends on to be the canonical ones, that are part of the official Scala distribution. (The distribution itself is defined by the new scala-dist maven artifact.)

New features in the 2.11 series

This release contains all of the bug fixes and improvements made in the 2.10 series, as well as:

License clarification

Scala is now distributed under the standard 3-clause BSD license. Originally, the same 3-clause BSD license was adopted, but slightly reworded over the years, and the Scala License was born. Were now back to the standard formulation to avoid confusion.

Continue reading on www.scala-lang.org