Re: [scala-internals] Scala 2.12.0-M1 is available

FYI, I've just published shapeless-2.2.0 for Scala 2.12.0-M1 to Maven
Central and I'm also publishing automatic snapshots for 2.12.0-M1.

All looks good thus far ...

Cheers,


Miles


On Tue, May 5, 2015 at 3:35 PM, Lukas Rytz <[email protected]> wrote:
> We are very pleased to announce the release of Scala 2.12.0-M1!
>
> Download a distribution from scala-lang.org
> Obtain it via Maven Central
>
> Code that compiles on 2.11.x without deprecation warnings should compile on
> 2.12.x (we do not guarantee this for experimental APIs, such as reflection).
> If not, please file an issue.
>
> We are working with the community to ensure availability of the core
> projects of the Scala 2.12 eco-system. This release is not binary compatible
> with the 2.11.x series, to allow us to keep improving the Scala standard
> library.
>
> The Scala 2.12 series targets Java 8. Programs written in Scala 2.12,
> including the Scala 2.12 compiler, can only be executed on Java 8 or newer.
> Note that the current milestone release (2.12.0-M1) still targets Java 6.
>
> New Features in the 2.12 Series
>
> Scala 2.12 contains all of the bug fixes and improvements made in the 2.11
> series.
>
> At the current stage in the milestone cycle, Scala 2.12 is still very
> similar to Scala 2.11.
>
> The following changes are planned for Scala 2.12:
>
> Java 8 style closures. The Scala compiler will emit closure classes
> (lambdas) in the same manner as Java 8. The design notes for this feature
> are available in this gist.
> Lambda syntax for SAM types. Similar to Java 8, Scala 2.12 allows
> instantiating any type with one single abstract method by passing a lambda.
> This feature is already avalable in Scala 2.11 using the -Xexperimental
> compiler option. It improves the experience of using libraries written for
> Java 8 in Scala.
> New backend and optimizer. The "GenBCode" backend, which is already
> available in Scala 2.11 using the -Ybackend:GenBCode compiler option, will
> be enabled by default. Scala 2.12 will also ship with a new inliner and
> bytecode optimizer. We keep track of issues and work items for the new
> optimizer on the scala-opt repostiory issue tracker.
>
> The above list is incomplete and will be extendend during the Scala 2.12
> milestone cycle.
>
> Up the current milestone, the Scala team and contributors fixed 47 bugs that
> are exclusive to Scala 2.12.0. During the development cycle of Scala 2.12,
> we will continue to backport issues to 2.11 whenever feasible. With the
> release of 2.12.0, backports to 2.11 will be dialed back.
>
> Removed Modules
>
> The following modules have been removed from the Scala 2.12 distribution:
>
> The Scala actors library is no longer released with Scala 2.12. We recommend
> that you use the Akka actors library instead. To migrate your code, follow
> the Scala actors migration guide before upgrading your project to Scala
> 2.12.
> The Scala distribution archives and the scala-library-all maven dependency
> no longer inlcude Akka actors. To use the Akka actors library, add it to
> your project as a dependency.
> The continuations plugin is no longer shipped with the Scala 2.12
> distribution.
>
> Contributors
>
> A big thank you to everyone who's helped improve Scala by reporting bugs,
> improving our documentation, spreading kindness in mailing lists and other
> public fora, and submitting and reviewing pull requests! You are all
> magnificent.
>
> According to git shortlog -sn --no-merges 2.11.x..v2.12.0-M1, 33 people
> contributed to this major release: Jason Zaugg, Lukas Rytz, A. P. Marki, Rex
> Kerr, Kato Kazuyoshi, Max Bileschi, jxcoder, François Garillot, rubyu,
> Adriaan Moors, Dominik Gruntz, Evgeny Vereshchagin, Marc Siegel, Masato
> Sogame, Simon Ochsenreither, Todd Vierling, Viktor Klang, cchantep, Denton
> Cockburn, Paolo Giarrusso, Denis Rosset, Roman Hargrave, Rui Gonçalves,
> Shadaj, harryhuk, Steven Scott, Antoine Gourlay, Aleksandar Prokopec, Lukas
> Elmer, Erlend Hamnaberg, Maks Atygaev, Malte Isberner, dgruntz. Thank you!
>
> These release notes are hosted on GitHub and are continuously updated during
> the Scala 2.12.0 release cycle. You are kindly invited to contribute!
>
> Reporting Bugs
>
> Please file any bugs you encounter on our issue tracker. If you're unsure
> whether something is a bug, please contact the scala-user mailing list.
> Before creating a new issue, search search the issue tracker to see if your
> bug has already been reported.
>
> Scala IDE for Eclipse
>
> A release of the Scala IDE for Eclipse for Scala 2.12 will be available
> together with the release.
>
> Note that for the current milestone (2.12.0-M1), the Scala IDE is not yet
> available.
>
> Available Projects
>
> Please refer to the list of libraries and frameworks available for Scala
> 2.12.
>
> Binary Compatibility
>
> Since Sala 2.11, minor releases of Scala are binary compatible. Scala 2.12
> continues this tradition: every 2.12.x release will be binary compatible
> with 2.12.0. Note that milestone releases and release candidates are not
> binary compatible with any other release.
>
> Definition
>
> 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 you're compiling with, as long as they're 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.
>
> 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).
>
> Meta
>
> Note that so far we've only talked about the jars generated by scalac for
> the standard library and reflection.
> Our policies do not extend to the meta-issue: ensuring binary compatibility
> for bytecode generated from identical sources, by different version of
> scalac? (The same problem exists for compiling on different JDKs.) While we
> strive to achieve this, it's not something we can test in general. Notable
> examples where we know meta-binary compatibility is hard to achieve:
> specialisation and the optimizer.
>
> In short, if binary compatibility of your library is important to you, use
> MiMa to verify compatibility before releasing. Compiling identical sources
> with different versions of the Scala compiler (or on different JVM
> versions!) could result in binary incompatible bytecode. This is rare, and
> we try to avoid it, but we can't guarantee it will never happen.
>
> Concretely
>
> We guarantee forwards and backwards compatibility of the "org.scala-lang" %
> "scala-library" % "2.12.x" and "org.scala-lang" % "scala-reflect" % "2.12.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 andscala.reflect.runtime, though we
> will only break compatibility for severe bugs here.
>
>
> --
> 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 [email protected].
> For more options, visit https://groups.google.com/d/optout.



-- 
Miles Sabin
tel: +44 7813 944 528
skype: milessabin
gtalk: [email protected]
http://milessabin.com/blog
http://twitter.com/milessabin

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