Scala Meeting report, 2009-12-01

> * MSIL: Testing
> - We have no idea about the quality of the generated bytecode. We need a tool that runs our test suite on .NET (partest uses actors, and they don't work on .NET). We will work on a simplified version of partest for use on msil.

A while back I had asked about helping with this, but haven't found the time. I can probably make some time now. I could split time helping with testing here, and testing for parallel collections, if that helps.

On Wed, Dec 2, 2009 at 11:03 AM, Antonio Cunei <antonio.cunei@epfl.ch> wrote:

We are currently publishing a summary of each of the weekly meetings of the Scala Core Team.

This information is made available as a service to the community. It is by necessity rather brief and gives only a rough approximation of the main points of discussions explored during each meeting; it should not be taken as a source of reliable information, nor as a record of concrete or firm decisions, nor as anything other than a record of a simple discussion.

The summary that follows is primarily intended for Scala contributors and maintainers. If you are not a contributor to the Scala system, the information below is unlikely to be very useful to you, and you might lack some of the necessary background to make sense of all the discussion items.

We do not have enough people on the team to be able to write a more complete record, and we might also not have the resources to discuss every point in detail afterwards. Nevertheless, we hope that this record, cursory as it is, is better than nothing.

------------------------------------------------------------------------------


Report from the Scala Core Team meeting, 2009-12-01:


People attending the meeting: Martin, Iulian, Donna, Eugene, Alex, Hubert, Tiark, Gilles, Toni, Adriaan, Lukas, Philipp.


* Current work:
 - bug fixing
 - work on the msil backend
 - work on new scaladoc, including improvements to deal with inherited members
 - work on the jvm6 backend (taking advantage of the new type-checking verifier, which needs more type information)
 - documentation of the collection library
 - work on the Eclipse build manager
 - fork-join framework and parallel collections

* jvm5 - jvm6 (there was a long discussion, below are the topics that were discussed, not necessarily in this order)
 - provide both versions for jvm5 & jvm6?
 - we could have a -jvmX suffix for all released versions
 - we can push 1.5 as the default, but provide a complete toolchain for 1.6 on a different download page.
 - will only provide jvm5
 - technical challenges:
   - must build final release on jvm5 (can't build on jvm6 with target jvm5 because isEmpty error is masked by implicit on jvm5)
FJ
     - include compiled backported library (by javac on jvm6 with target jvm5)
     - do dynamic loading on startup of actors framework -- make it reusable so we can use it later for parallel collections
 - weighing the benefits
   - main goals: Scala users = happy, applications run
   - technical goals: performance of actors/bytecode verifier
   - what's the gain of a jvm6 build?
     - forkjoin (because actors are included in the std lib
       - can we provide them separately?
       - can we do dynamic fallback?
     - backport of the FJ library doesn't work well on jvm5
     - performance of new bytecode verifier
   - parallel collections: could also do the fallback
   - major downside of having two builds: DLL HELL
     - we're at the bottom, if we split, everyone will have to split
 - naming: include required jvm version in the scala version?
   - explicitly include jvm version to reduce confusion
 - guidance: guide them towards using jvm5, will migrate to recommending jvm6 for scala 2.9
 - communication: endorse jvm5 as the official, more prominent on the download page + warning for 1.6 download?
 - packaging: can we specify that scala-2.8.x-jvm5 conflicts with scala-2.8.x-jvm6? (in maven/sbt/...)?
 - impact on library providers: need to provide their libraries for both versions, can't mix and match between jvm6 and jvm5?

 In the end:
 - We will have a single release: the 1.6-specific code will be loaded automatically for additional performance on 1.6 VMs, but all will run on 1.5 in any case
 - The new 1.6 backend (generating the 1.6 classfiles with the new verifier information) may be added to the 2.8 compiler if time allows; it will not be the default target, however
 - 1.6 will become the recommended platform in a future Scala 2.9


* MSIL: Testing
 - We have no idea about the quality of the generated bytecode. We need a tool that runs our test suite on .NET (partest uses actors, and they don't work on .NET). We will work on a simplified version of partest for use on msil.

* Scaladoc 2
 - Should we ship scaladoc2 docs&tool with 2.8?
 - Let's wait a couple of weeks for the code to stabilize

* 2.8 Release Notes
 These are the features that will be included in 2.8. The 2.8 Release Notes will be based on this list.

 The following features are new, or significantly improved:
 - Redesigned collection library
 - New array implementation, manifests for polymorphic arrays
 - Type specialization
 - Named and default arguments
 - Package objects
 - Beefed up Scala Swing libraries, better documentation
 - Support for continuations (to be included after the first beta)
 - Revamped REPL
 - Implicits changes (refined implicit resolution, priorities)
 - Improved equality
 - Packrat parser combinators
 - Improved XML library
 - Type constructor inference
 - Early initializers
 - Improved Annotations (support for nested Java annotations)
 - Enhanced actors: daemon actors, new Reactors, pluggable schedulers, significant performance improvements on 1.6 JVMs.
 - Support for the 1.6 target (will likely be included)

 Internal improvements:
 - New presentation compiler, offers a better support to IDEs
 - Compiler code will be optimised

 Bug fixes:
 - Huge list of bug fixes; the most significant are listed at: http://www.scala-lang.org/node/299

 Additional tools:
 - Scaladoc 2
 - New scalap, contributed by Ilya Sergey
 - Much improved Eclipse plugin

* Website downtime
 - A number of modules need upgrading, and a little maintenance is necessary. There will be a few longish downtimes (2-3h) during December/January.

Please, do not fall into the trap of calling the next Scala version "2.9". For one thing, if it is decided to make JVM 6 the default, breaking binary compatibility, then "3.0" would be a better target.   One way or the other, do allow yourselves the chance of choosing the best numbering at a time when it becomes clear what it might be.
On Wed, Dec 2, 2009 at 3:03 PM, Antonio Cunei <antonio.cunei@epfl.ch> wrote:

We are currently publishing a summary of each of the weekly meetings of the Scala Core Team.

This information is made available as a service to the community. It is by necessity rather brief and gives only a rough approximation of the main points of discussions explored during each meeting; it should not be taken as a source of reliable information, nor as a record of concrete or firm decisions, nor as anything other than a record of a simple discussion.

The summary that follows is primarily intended for Scala contributors and maintainers. If you are not a contributor to the Scala system, the information below is unlikely to be very useful to you, and you might lack some of the necessary background to make sense of all the discussion items.

We do not have enough people on the team to be able to write a more complete record, and we might also not have the resources to discuss every point in detail afterwards. Nevertheless, we hope that this record, cursory as it is, is better than nothing.

------------------------------------------------------------------------------


Report from the Scala Core Team meeting, 2009-12-01:


People attending the meeting: Martin, Iulian, Donna, Eugene, Alex, Hubert, Tiark, Gilles, Toni, Adriaan, Lukas, Philipp.


* Current work:
 - bug fixing
 - work on the msil backend
 - work on new scaladoc, including improvements to deal with inherited members
 - work on the jvm6 backend (taking advantage of the new type-checking verifier, which needs more type information)
 - documentation of the collection library
 - work on the Eclipse build manager
 - fork-join framework and parallel collections

* jvm5 - jvm6 (there was a long discussion, below are the topics that were discussed, not necessarily in this order)
 - provide both versions for jvm5 & jvm6?
 - we could have a -jvmX suffix for all released versions
 - we can push 1.5 as the default, but provide a complete toolchain for 1.6 on a different download page.
 - will only provide jvm5
 - technical challenges:
   - must build final release on jvm5 (can't build on jvm6 with target jvm5 because isEmpty error is masked by implicit on jvm5)
FJ
     - include compiled backported library (by javac on jvm6 with target jvm5)
     - do dynamic loading on startup of actors framework -- make it reusable so we can use it later for parallel collections
 - weighing the benefits
   - main goals: Scala users = happy, applications run
   - technical goals: performance of actors/bytecode verifier
   - what's the gain of a jvm6 build?
     - forkjoin (because actors are included in the std lib
       - can we provide them separately?
       - can we do dynamic fallback?
     - backport of the FJ library doesn't work well on jvm5
     - performance of new bytecode verifier
   - parallel collections: could also do the fallback
   - major downside of having two builds: DLL HELL
     - we're at the bottom, if we split, everyone will have to split
 - naming: include required jvm version in the scala version?
   - explicitly include jvm version to reduce confusion
 - guidance: guide them towards using jvm5, will migrate to recommending jvm6 for scala 2.9
 - communication: endorse jvm5 as the official, more prominent on the download page + warning for 1.6 download?
 - packaging: can we specify that scala-2.8.x-jvm5 conflicts with scala-2.8.x-jvm6? (in maven/sbt/...)?
 - impact on library providers: need to provide their libraries for both versions, can't mix and match between jvm6 and jvm5?

 In the end:
 - We will have a single release: the 1.6-specific code will be loaded automatically for additional performance on 1.6 VMs, but all will run on 1.5 in any case
 - The new 1.6 backend (generating the 1.6 classfiles with the new verifier information) may be added to the 2.8 compiler if time allows; it will not be the default target, however
 - 1.6 will become the recommended platform in a future Scala 2.9


* MSIL: Testing
 - We have no idea about the quality of the generated bytecode. We need a tool that runs our test suite on .NET (partest uses actors, and they don't work on .NET). We will work on a simplified version of partest for use on msil.

* Scaladoc 2
 - Should we ship scaladoc2 docs&tool with 2.8?
 - Let's wait a couple of weeks for the code to stabilize

* 2.8 Release Notes
 These are the features that will be included in 2.8. The 2.8 Release Notes will be based on this list.

 The following features are new, or significantly improved:
 - Redesigned collection library
 - New array implementation, manifests for polymorphic arrays
 - Type specialization
 - Named and default arguments
 - Package objects
 - Beefed up Scala Swing libraries, better documentation
 - Support for continuations (to be included after the first beta)
 - Revamped REPL
 - Implicits changes (refined implicit resolution, priorities)
 - Improved equality
 - Packrat parser combinators
 - Improved XML library
 - Type constructor inference
 - Early initializers
 - Improved Annotations (support for nested Java annotations)
 - Enhanced actors: daemon actors, new Reactors, pluggable schedulers, significant performance improvements on 1.6 JVMs.
 - Support for the 1.6 target (will likely be included)

 Internal improvements:
 - New presentation compiler, offers a better support to IDEs
 - Compiler code will be optimised

 Bug fixes:
 - Huge list of bug fixes; the most significant are listed at: http://www.scala-lang.org/node/299

 Additional tools:
 - Scaladoc 2
 - New scalap, contributed by Ilya Sergey
 - Much improved Eclipse plugin

* Website downtime
 - A number of modules need upgrading, and a little maintenance is necessary. There will be a few longish downtimes (2-3h) during December/January.

--
Daniel C. Sobral

I travel to the future all the time.

I have been reading the trac list for Scala 2.8, and I think it would be better if the "2.8 regression" tickets were removed. This might be non-trivial, I understand, but... it is plain weird listing a fix for a bug that was never released.

On Wed, Dec 2, 2009 at 3:03 PM, Antonio Cunei <antonio.cunei@epfl.ch> wrote:

We are currently publishing a summary of each of the weekly meetings of the Scala Core Team.

This information is made available as a service to the community. It is by necessity rather brief and gives only a rough approximation of the main points of discussions explored during each meeting; it should not be taken as a source of reliable information, nor as a record of concrete or firm decisions, nor as anything other than a record of a simple discussion.

The summary that follows is primarily intended for Scala contributors and maintainers. If you are not a contributor to the Scala system, the information below is unlikely to be very useful to you, and you might lack some of the necessary background to make sense of all the discussion items.

We do not have enough people on the team to be able to write a more complete record, and we might also not have the resources to discuss every point in detail afterwards. Nevertheless, we hope that this record, cursory as it is, is better than nothing.

------------------------------------------------------------------------------


Report from the Scala Core Team meeting, 2009-12-01:


People attending the meeting: Martin, Iulian, Donna, Eugene, Alex, Hubert, Tiark, Gilles, Toni, Adriaan, Lukas, Philipp.


* Current work:
 - bug fixing
 - work on the msil backend
 - work on new scaladoc, including improvements to deal with inherited members
 - work on the jvm6 backend (taking advantage of the new type-checking verifier, which needs more type information)
 - documentation of the collection library
 - work on the Eclipse build manager
 - fork-join framework and parallel collections

* jvm5 - jvm6 (there was a long discussion, below are the topics that were discussed, not necessarily in this order)
 - provide both versions for jvm5 & jvm6?
 - we could have a -jvmX suffix for all released versions
 - we can push 1.5 as the default, but provide a complete toolchain for 1.6 on a different download page.
 - will only provide jvm5
 - technical challenges:
   - must build final release on jvm5 (can't build on jvm6 with target jvm5 because isEmpty error is masked by implicit on jvm5)
FJ
     - include compiled backported library (by javac on jvm6 with target jvm5)
     - do dynamic loading on startup of actors framework -- make it reusable so we can use it later for parallel collections
 - weighing the benefits
   - main goals: Scala users = happy, applications run
   - technical goals: performance of actors/bytecode verifier
   - what's the gain of a jvm6 build?
     - forkjoin (because actors are included in the std lib
       - can we provide them separately?
       - can we do dynamic fallback?
     - backport of the FJ library doesn't work well on jvm5
     - performance of new bytecode verifier
   - parallel collections: could also do the fallback
   - major downside of having two builds: DLL HELL
     - we're at the bottom, if we split, everyone will have to split
 - naming: include required jvm version in the scala version?
   - explicitly include jvm version to reduce confusion
 - guidance: guide them towards using jvm5, will migrate to recommending jvm6 for scala 2.9
 - communication: endorse jvm5 as the official, more prominent on the download page + warning for 1.6 download?
 - packaging: can we specify that scala-2.8.x-jvm5 conflicts with scala-2.8.x-jvm6? (in maven/sbt/...)?
 - impact on library providers: need to provide their libraries for both versions, can't mix and match between jvm6 and jvm5?

 In the end:
 - We will have a single release: the 1.6-specific code will be loaded automatically for additional performance on 1.6 VMs, but all will run on 1.5 in any case
 - The new 1.6 backend (generating the 1.6 classfiles with the new verifier information) may be added to the 2.8 compiler if time allows; it will not be the default target, however
 - 1.6 will become the recommended platform in a future Scala 2.9


* MSIL: Testing
 - We have no idea about the quality of the generated bytecode. We need a tool that runs our test suite on .NET (partest uses actors, and they don't work on .NET). We will work on a simplified version of partest for use on msil.

* Scaladoc 2
 - Should we ship scaladoc2 docs&tool with 2.8?
 - Let's wait a couple of weeks for the code to stabilize

* 2.8 Release Notes
 These are the features that will be included in 2.8. The 2.8 Release Notes will be based on this list.

 The following features are new, or significantly improved:
 - Redesigned collection library
 - New array implementation, manifests for polymorphic arrays
 - Type specialization
 - Named and default arguments
 - Package objects
 - Beefed up Scala Swing libraries, better documentation
 - Support for continuations (to be included after the first beta)
 - Revamped REPL
 - Implicits changes (refined implicit resolution, priorities)
 - Improved equality
 - Packrat parser combinators
 - Improved XML library
 - Type constructor inference
 - Early initializers
 - Improved Annotations (support for nested Java annotations)
 - Enhanced actors: daemon actors, new Reactors, pluggable schedulers, significant performance improvements on 1.6 JVMs.
 - Support for the 1.6 target (will likely be included)

 Internal improvements:
 - New presentation compiler, offers a better support to IDEs
 - Compiler code will be optimised

 Bug fixes:
 - Huge list of bug fixes; the most significant are listed at: http://www.scala-lang.org/node/299

 Additional tools:
 - Scaladoc 2
 - New scalap, contributed by Ilya Sergey
 - Much improved Eclipse plugin

* Website downtime
 - A number of modules need upgrading, and a little maintenance is necessary. There will be a few longish downtimes (2-3h) during December/January.

--
Daniel C. Sobral

I travel to the future all the time.

Indeed they shouldn't be listed, only tickets that refer to bugs present in
previous released versions should have their "Fixed in version" field set.

Can you point to specific tickets? I'll be happy to modify them accordingly.

Many minor bug fixes do not even appear in the list, incidentally; we
generally set the "Fixed in version" field only for significant bugs. The
resulting list is intended to be a "What's new?" page, in the end.

Toni

Daniel Sobral wrote:
> I have been reading the trac list for Scala 2.8, and I think it would be
> better if the "2.8 regression" tickets were removed. This might be
> non-trivial, I understand, but... it is plain weird listing a fix for a bug
> that was never released.
>
> On Wed, Dec 2, 2009 at 3:03 PM, Antonio Cunei wrote:
>
>> We are currently publishing a summary of each of the weekly meetings of the
>> Scala Core Team.
>>
>> This information is made available as a service to the community. It is by
>> necessity rather brief and gives only a rough approximation of the main
>> points of discussions explored during each meeting; it should not be taken
>> as a source of reliable information, nor as a record of concrete or firm
>> decisions, nor as anything other than a record of a simple discussion.
>>
>> The summary that follows is primarily intended for Scala contributors and
>> maintainers. If you are not a contributor to the Scala system, the
>> information below is unlikely to be very useful to you, and you might lack
>> some of the necessary background to make sense of all the discussion items.
>>
>> We do not have enough people on the team to be able to write a more
>> complete record, and we might also not have the resources to discuss every
>> point in detail afterwards. Nevertheless, we hope that this record, cursory
>> as it is, is better than nothing.
>>
>>
>> ------------------------------------------------------------------------------
>>
>>
>> Report from the Scala Core Team meeting, 2009-12-01:
>>
>>
>> People attending the meeting: Martin, Iulian, Donna, Eugene, Alex, Hubert,
>> Tiark, Gilles, Toni, Adriaan, Lukas, Philipp.
>>
>>
>> * Current work:
>> - bug fixing
>> - work on the msil backend
>> - work on new scaladoc, including improvements to deal with inherited
>> members
>> - work on the jvm6 backend (taking advantage of the new type-checking
>> verifier, which needs more type information)
>> - documentation of the collection library
>> - work on the Eclipse build manager
>> - fork-join framework and parallel collections
>>
>> * jvm5 - jvm6 (there was a long discussion, below are the topics that were
>> discussed, not necessarily in this order)
>> - provide both versions for jvm5 & jvm6?
>> - we could have a -jvmX suffix for all released versions
>> - we can push 1.5 as the default, but provide a complete toolchain for 1.6
>> on a different download page.
>> - will only provide jvm5
>> - technical challenges:
>> - must build final release on jvm5 (can't build on jvm6 with target jvm5
>> because isEmpty error is masked by implicit on jvm5)
>> FJ
>> - include compiled backported library (by javac on jvm6 with target
>> jvm5)
>> - do dynamic loading on startup of actors framework -- make it
>> reusable so we can use it later for parallel collections
>> - weighing the benefits
>> - main goals: Scala users = happy, applications run
>> - technical goals: performance of actors/bytecode verifier
>> - what's the gain of a jvm6 build?
>> - forkjoin (because actors are included in the std lib
>> - can we provide them separately?
>> - can we do dynamic fallback?
>> - backport of the FJ library doesn't work well on jvm5
>> - performance of new bytecode verifier
>> - parallel collections: could also do the fallback
>> - major downside of having two builds: DLL HELL
>> - we're at the bottom, if we split, everyone will have to split
>> - naming: include required jvm version in the scala version?
>> - explicitly include jvm version to reduce confusion
>> - guidance: guide them towards using jvm5, will migrate to recommending
>> jvm6 for scala 2.9
>> - communication: endorse jvm5 as the official, more prominent on the
>> download page + warning for 1.6 download?
>> - packaging: can we specify that scala-2.8.x-jvm5 conflicts with
>> scala-2.8.x-jvm6? (in maven/sbt/...)?
>> - impact on library providers: need to provide their libraries for both
>> versions, can't mix and match between jvm6 and jvm5?
>>
>> In the end:
>> - We will have a single release: the 1.6-specific code will be loaded
>> automatically for additional performance on 1.6 VMs, but all will run on 1.5
>> in any case
>> - The new 1.6 backend (generating the 1.6 classfiles with the new verifier
>> information) may be added to the 2.8 compiler if time allows; it will not be
>> the default target, however
>> - 1.6 will become the recommended platform in a future Scala 2.9
>>
>>
>> * MSIL: Testing
>> - We have no idea about the quality of the generated bytecode. We need a
>> tool that runs our test suite on .NET (partest uses actors, and they don't
>> work on .NET). We will work on a simplified version of partest for use on
>> msil.
>>
>> * Scaladoc 2
>> - Should we ship scaladoc2 docs&tool with 2.8?
>> - Let's wait a couple of weeks for the code to stabilize
>>
>> * 2.8 Release Notes
>> These are the features that will be included in 2.8. The 2.8 Release Notes
>> will be based on this list.
>>
>> The following features are new, or significantly improved:
>> - Redesigned collection library
>> - New array implementation, manifests for polymorphic arrays
>> - Type specialization
>> - Named and default arguments
>> - Package objects
>> - Beefed up Scala Swing libraries, better documentation
>> - Support for continuations (to be included after the first beta)
>> - Revamped REPL
>> - Implicits changes (refined implicit resolution, priorities)
>> - Improved equality
>> - Packrat parser combinators
>> - Improved XML library
>> - Type constructor inference
>> - Early initializers
>> - Improved Annotations (support for nested Java annotations)
>> - Enhanced actors: daemon actors, new Reactors, pluggable schedulers,
>> significant performance improvements on 1.6 JVMs.
>> - Support for the 1.6 target (will likely be included)
>>
>> Internal improvements:
>> - New presentation compiler, offers a better support to IDEs
>> - Compiler code will be optimised
>>
>> Bug fixes:
>> - Huge list of bug fixes; the most significant are listed at:
>> http://www.scala-lang.org/node/299
>>
>> Additional tools:
>> - Scaladoc 2
>> - New scalap, contributed by Ilya Sergey
>> - Much improved Eclipse plugin
>>
>> * Website downtime
>> - A number of modules need upgrading, and a little maintenance is
>> necessary. There will be a few longish downtimes (2-3h) during
>> December/January.
>>
>>
>
>

Help would be very much appreciated!

We have a tool called "partest" which compiles our test cases and runs them.
The executor uses actors, which are not available on Scala.NET. So the idea
is to write a simple non-parallel partest-executor which runs on .NET.

This should not be too hard in itself. However, I expect some problems because
 - partest uses java libraries in some places (I/O, there might be more)
 - partest would actually be the first real-word program running on Scala.NET,
   and we might hit some bugs.

If you want to give it a go, just check out the msil-branch
  http://lampsvn.epfl.ch/svn-repos/scala/scala-msil/trunk
and run "ant msil". You'll get a .NET-target compiler in
  build/msil-pack/

We should make a branch of the main partest sources. Similar to dotnet-library,
just copy the folder `src/partest` to `src/dotnet-partest` and start hacking.

Lukas



On Wed, Dec 2, 2009 at 18:56, Josh Cough <joshcough@gmail.com> wrote:

> * MSIL: Testing
> - We have no idea about the quality of the generated bytecode. We need a tool that runs our test suite on .NET (partest uses actors, and they don't work on .NET). We will work on a simplified version of partest for use on msil.

A while back I had asked about helping with this, but haven't found the time. I can probably make some time now. I could split time helping with testing here, and testing for parallel collections, if that helps.

On Wed, Dec 2, 2009 at 11:03 AM, Antonio Cunei <antonio.cunei@epfl.ch> wrote:

We are currently publishing a summary of each of the weekly meetings of the Scala Core Team.

This information is made available as a service to the community. It is by necessity rather brief and gives only a rough approximation of the main points of discussions explored during each meeting; it should not be taken as a source of reliable information, nor as a record of concrete or firm decisions, nor as anything other than a record of a simple discussion.

The summary that follows is primarily intended for Scala contributors and maintainers. If you are not a contributor to the Scala system, the information below is unlikely to be very useful to you, and you might lack some of the necessary background to make sense of all the discussion items.

We do not have enough people on the team to be able to write a more complete record, and we might also not have the resources to discuss every point in detail afterwards. Nevertheless, we hope that this record, cursory as it is, is better than nothing.

------------------------------------------------------------------------------


Report from the Scala Core Team meeting, 2009-12-01:


People attending the meeting: Martin, Iulian, Donna, Eugene, Alex, Hubert, Tiark, Gilles, Toni, Adriaan, Lukas, Philipp.


* Current work:
 - bug fixing
 - work on the msil backend
 - work on new scaladoc, including improvements to deal with inherited members
 - work on the jvm6 backend (taking advantage of the new type-checking verifier, which needs more type information)
 - documentation of the collection library
 - work on the Eclipse build manager
 - fork-join framework and parallel collections

* jvm5 - jvm6 (there was a long discussion, below are the topics that were discussed, not necessarily in this order)
 - provide both versions for jvm5 & jvm6?
 - we could have a -jvmX suffix for all released versions
 - we can push 1.5 as the default, but provide a complete toolchain for 1.6 on a different download page.
 - will only provide jvm5
 - technical challenges:
   - must build final release on jvm5 (can't build on jvm6 with target jvm5 because isEmpty error is masked by implicit on jvm5)
FJ
     - include compiled backported library (by javac on jvm6 with target jvm5)
     - do dynamic loading on startup of actors framework -- make it reusable so we can use it later for parallel collections
 - weighing the benefits
   - main goals: Scala users = happy, applications run
   - technical goals: performance of actors/bytecode verifier
   - what's the gain of a jvm6 build?
     - forkjoin (because actors are included in the std lib
       - can we provide them separately?
       - can we do dynamic fallback?
     - backport of the FJ library doesn't work well on jvm5
     - performance of new bytecode verifier
   - parallel collections: could also do the fallback
   - major downside of having two builds: DLL HELL
     - we're at the bottom, if we split, everyone will have to split
 - naming: include required jvm version in the scala version?
   - explicitly include jvm version to reduce confusion
 - guidance: guide them towards using jvm5, will migrate to recommending jvm6 for scala 2.9
 - communication: endorse jvm5 as the official, more prominent on the download page + warning for 1.6 download?
 - packaging: can we specify that scala-2.8.x-jvm5 conflicts with scala-2.8.x-jvm6? (in maven/sbt/...)?
 - impact on library providers: need to provide their libraries for both versions, can't mix and match between jvm6 and jvm5?

 In the end:
 - We will have a single release: the 1.6-specific code will be loaded automatically for additional performance on 1.6 VMs, but all will run on 1.5 in any case
 - The new 1.6 backend (generating the 1.6 classfiles with the new verifier information) may be added to the 2.8 compiler if time allows; it will not be the default target, however
 - 1.6 will become the recommended platform in a future Scala 2.9


* MSIL: Testing
 - We have no idea about the quality of the generated bytecode. We need a tool that runs our test suite on .NET (partest uses actors, and they don't work on .NET). We will work on a simplified version of partest for use on msil.

* Scaladoc 2
 - Should we ship scaladoc2 docs&tool with 2.8?
 - Let's wait a couple of weeks for the code to stabilize

* 2.8 Release Notes
 These are the features that will be included in 2.8. The 2.8 Release Notes will be based on this list.

 The following features are new, or significantly improved:
 - Redesigned collection library
 - New array implementation, manifests for polymorphic arrays
 - Type specialization
 - Named and default arguments
 - Package objects
 - Beefed up Scala Swing libraries, better documentation
 - Support for continuations (to be included after the first beta)
 - Revamped REPL
 - Implicits changes (refined implicit resolution, priorities)
 - Improved equality
 - Packrat parser combinators
 - Improved XML library
 - Type constructor inference
 - Early initializers
 - Improved Annotations (support for nested Java annotations)
 - Enhanced actors: daemon actors, new Reactors, pluggable schedulers, significant performance improvements on 1.6 JVMs.
 - Support for the 1.6 target (will likely be included)

 Internal improvements:
 - New presentation compiler, offers a better support to IDEs
 - Compiler code will be optimised

 Bug fixes:
 - Huge list of bug fixes; the most significant are listed at: http://www.scala-lang.org/node/299

 Additional tools:
 - Scaladoc 2
 - New scalap, contributed by Ilya Sergey
 - Much improved Eclipse plugin

* Website downtime
 - A number of modules need upgrading, and a little maintenance is necessary. There will be a few longish downtimes (2-3h) during December/January.

I just saw some tickets listed in that page whose description was "2.8 regression" or something similar. I think grepping for "regression" or "2.8" should find the most offensive cases. :-)

On Wed, Dec 2, 2009 at 5:41 PM, Antonio Cunei <antonio.cunei@epfl.ch> wrote:

Indeed they shouldn't be listed, only tickets that refer to bugs present in previous released versions should have their "Fixed in version" field set.

Can you point to specific tickets? I'll be happy to modify them accordingly.

Many minor bug fixes do not even appear in the list, incidentally; we generally set the "Fixed in version" field only for significant bugs. The resulting list is intended to be a "What's new?" page, in the end.

Toni


Daniel Sobral wrote:

I have been reading the trac list for Scala 2.8, and I think it would be
better if the "2.8 regression" tickets were removed. This might be
non-trivial, I understand, but... it is plain weird listing a fix for a bug
that was never released.

On Wed, Dec 2, 2009 at 3:03 PM, Antonio Cunei <antonio.cunei@epfl.ch> wrote:

We are currently publishing a summary of each of the weekly meetings of the
Scala Core Team.

This information is made available as a service to the community. It is by
necessity rather brief and gives only a rough approximation of the main
points of discussions explored during each meeting; it should not be taken
as a source of reliable information, nor as a record of concrete or firm
decisions, nor as anything other than a record of a simple discussion.

The summary that follows is primarily intended for Scala contributors and
maintainers. If you are not a contributor to the Scala system, the
information below is unlikely to be very useful to you, and you might lack
some of the necessary background to make sense of all the discussion items.

We do not have enough people on the team to be able to write a more
complete record, and we might also not have the resources to discuss every
point in detail afterwards. Nevertheless, we hope that this record, cursory
as it is, is better than nothing.


------------------------------------------------------------------------------


Report from the Scala Core Team meeting, 2009-12-01:


People attending the meeting: Martin, Iulian, Donna, Eugene, Alex, Hubert,
Tiark, Gilles, Toni, Adriaan, Lukas, Philipp.


* Current work:
 - bug fixing
 - work on the msil backend
 - work on new scaladoc, including improvements to deal with inherited
members
 - work on the jvm6 backend (taking advantage of the new type-checking
verifier, which needs more type information)
 - documentation of the collection library
 - work on the Eclipse build manager
 - fork-join framework and parallel collections

* jvm5 - jvm6 (there was a long discussion, below are the topics that were
discussed, not necessarily in this order)
 - provide both versions for jvm5 & jvm6?
 - we could have a -jvmX suffix for all released versions
 - we can push 1.5 as the default, but provide a complete toolchain for 1.6
on a different download page.
 - will only provide jvm5
 - technical challenges:
  - must build final release on jvm5 (can't build on jvm6 with target jvm5
because isEmpty error is masked by implicit on jvm5)
FJ
    - include compiled backported library (by javac on jvm6 with target
jvm5)
    - do dynamic loading on startup of actors framework -- make it
reusable so we can use it later for parallel collections
 - weighing the benefits
  - main goals: Scala users = happy, applications run
  - technical goals: performance of actors/bytecode verifier
  - what's the gain of a jvm6 build?
    - forkjoin (because actors are included in the std lib
      - can we provide them separately?
      - can we do dynamic fallback?
    - backport of the FJ library doesn't work well on jvm5
    - performance of new bytecode verifier
  - parallel collections: could also do the fallback
  - major downside of having two builds: DLL HELL
    - we're at the bottom, if we split, everyone will have to split
 - naming: include required jvm version in the scala version?
  - explicitly include jvm version to reduce confusion
 - guidance: guide them towards using jvm5, will migrate to recommending
jvm6 for scala 2.9
 - communication: endorse jvm5 as the official, more prominent on the
download page + warning for 1.6 download?
 - packaging: can we specify that scala-2.8.x-jvm5 conflicts with
scala-2.8.x-jvm6? (in maven/sbt/...)?
 - impact on library providers: need to provide their libraries for both
versions, can't mix and match between jvm6 and jvm5?

 In the end:
 - We will have a single release: the 1.6-specific code will be loaded
automatically for additional performance on 1.6 VMs, but all will run on 1.5
in any case
 - The new 1.6 backend (generating the 1.6 classfiles with the new verifier
information) may be added to the 2.8 compiler if time allows; it will not be
the default target, however
 - 1.6 will become the recommended platform in a future Scala 2.9


* MSIL: Testing
 - We have no idea about the quality of the generated bytecode. We need a
tool that runs our test suite on .NET (partest uses actors, and they don't
work on .NET). We will work on a simplified version of partest for use on
msil.

* Scaladoc 2
 - Should we ship scaladoc2 docs&tool with 2.8?
 - Let's wait a couple of weeks for the code to stabilize

* 2.8 Release Notes
 These are the features that will be included in 2.8. The 2.8 Release Notes
will be based on this list.

 The following features are new, or significantly improved:
 - Redesigned collection library
 - New array implementation, manifests for polymorphic arrays
 - Type specialization
 - Named and default arguments
 - Package objects
 - Beefed up Scala Swing libraries, better documentation
 - Support for continuations (to be included after the first beta)
 - Revamped REPL
 - Implicits changes (refined implicit resolution, priorities)
 - Improved equality
 - Packrat parser combinators
 - Improved XML library
 - Type constructor inference
 - Early initializers
 - Improved Annotations (support for nested Java annotations)
 - Enhanced actors: daemon actors, new Reactors, pluggable schedulers,
significant performance improvements on 1.6 JVMs.
 - Support for the 1.6 target (will likely be included)

 Internal improvements:
 - New presentation compiler, offers a better support to IDEs
 - Compiler code will be optimised

 Bug fixes:
 - Huge list of bug fixes; the most significant are listed at:
http://www.scala-lang.org/node/299

 Additional tools:
 - Scaladoc 2
 - New scalap, contributed by Ilya Sergey
 - Much improved Eclipse plugin

* Website downtime
 - A number of modules need upgrading, and a little maintenance is
necessary. There will be a few longish downtimes (2-3h) during
December/January.

--
Daniel C. Sobral

I travel to the future all the time.