Releasing 2.8 Beta

The recent change to cache classpath [1] leads to dramatic improvements in compile time for projects built with SBT, it was not specific at all to Scalaz.

It seems a low-risk change, perhaps you could branch from the RC7 tag and merge to avoid a new release candidate. But I'm sure everyone who wants a last minute change included would suggest this :)

-jason

http://lampsvn.epfl.ch/trac/scala/changeset/20438

On Tue, Jan 12, 2010 at 3:50 PM, martin odersky <martin.odersky@epfl.ch> wrote:

So we'd like to propose that the RC7 which was released last week will
be released as the official 2.8 beta by Friday this week. If people
strongly disagree because they think some critical functionality is
missing, they should please speak up between now and Thursday. But we
should keep in mind that every new RC extracts a price -- it has to be
prepared and then a lot of software has to be re-tested against it. So
it's a non-trivial commitment of time by quite a few people.

Cheers

On Tue, Jan 12, 2010 at 03:50:08PM +0100, martin odersky wrote:
> So we'd like to propose that the RC7 which was released last week will
> be released as the official 2.8 beta by Friday this week. If people
> strongly disagree because they think some critical functionality is
> missing, they should please speak up between now and Thursday. But we
> should keep in mind that every new RC extracts a price -- it has to be
> prepared and then a lot of software has to be re-tested against it. So
> it's a non-trivial commitment of time by quite a few people.

But the proposal is actually not RC7 but a variation on it with =>?
deprecated, right? After all the work I put into eliminating the trunk
deprecation warnings I would really love not to ship the first official
beta with a deprecated yet never-before-seen type alias and a zillion
uses of it. We just added =>? a week or two ago, let's delete it.

I am not so thrilled with RC7 because it has that now fixed bug with all
the dead matcherrors, and views are pretty broken because the methods
aren't there (see #2876) and I don't know why yet, but now at least I've
tunnelled through enough bugs that I can look at that soon.

I also think we badly need to do a complete review of all the parameter
names in the standard library, as they're all about to enter the API.
If with this beta we're asking people to start porting their software to
2.8, then we should avoid gratuitously changing them later; but I'd
really like not to inherit all the existing names by default, since to a
one they were written without this situation in mind.

OK, it seems with the SBT problems we need a RC8 anyway. And if we
can roll in the other fixes, so much the better. It's great that
MatchErrors are fixed. If we can fix view also, that would be great.

Regarding parameter names: Yes they need a review. But that will take
time. For the beta it's probably OK to makea release note that
parameter names for certain parts of the library are still in flux. We
would not expect people to change all their library calls to named
parameters anyway.

Given all this, when is the best time to do the RC? End of this week?
I'd really like to keep the momentum going now.

Cheers

On Wed, Jan 13, 2010 at 11:14:18AM +0100, martin odersky wrote:
> Given all this, when is the best time to do the RC? End of this week?
> I'd really like to keep the momentum going now.

End of this week looks good to me.

On 01/12/2010 06:50 AM, martin odersky wrote:
> At today's Scala meeting we tried to summarize the situation wrt the
> 2.8 beta. There are some issues that remain (they will be listed in
> the meeting report), but we felt none of these was a show-stopper.
> Remember that the goal of this beta is to have a stable version
> against which other tools are built, it's not supposed to be a
> flawless release. There will be release candidates for 2.8 final after
> that and there might also be another beta between now and the final
> release if that turns out to be necessary (I hope it won't).
>
> So we'd like to propose that the RC7 which was released last week will
> be released as the official 2.8 beta by Friday this week. If people
> strongly disagree because they think some critical functionality is
> missing, they should please speak up between now and Thursday. But we
> should keep in mind that every new RC extracts a price -- it has to be
> prepared and then a lot of software has to be re-tested against it. So
> it's a non-trivial commitment of time by quite a few people.
>
> We also decided that the Eclipse IDE will be released concurrently
> with the 2.8 beta but would be built against the latest trunk rather
> than the RC7. Generally, the Eclipse IDE will follow its own release
> schedule in the future, probably with more frequent updates than the
> release itself. As such it's just like the Netbeans and IntelliJ IDEs
> which are also not synchronized.

For our internal 44,000 line Scala versioned asset management system,
I'm slowly moving up the stack cutting code over to 2.8, it's been a
good amount of work.

I've converted Scala Migrations, Scala Guava and our internal Scala
common package to 2.8. I now need a port of Kestrel to 2.8 and then I
can finally do the main application.

What I've noticed so far is

1) No Java wrappers for java.util.concurrent.ConcurrentMap. The
putIfAbsent() method is the most important one for us. Looking at the
code, I see JMapWrapper is a case class and it would be good to extend
this class to share functionality for a JConconcurrentMapWrapper, but
extending case classes with another case class is deprecated now.

2) No Java wrappers for java.util.Hashtable which is the superclass to
java.util.Properties. Right now to iterate over elements I need to do
something like JavaConversions.asSet(props.entrySet), not too bad.

Regards,
Blair

Not HashTable, no, but Map (which is implemented by Properties), yes. See   http://stackoverflow.com/questions/2016268/getting-a-scala-map-from-a-java-properties

On Wed, Jan 13, 2010 at 4:13 PM, Blair Zajac <blair@orcaware.com> wrote:

On 01/12/2010 06:50 AM, martin odersky wrote:

At today's Scala meeting we tried to summarize the situation wrt the
2.8 beta. There are some issues that remain (they will be listed in
the meeting report), but we felt none of these was a show-stopper.
Remember that the goal of this beta is to have a stable version
against which other tools are built, it's not supposed to be a
flawless release. There will be release candidates for 2.8 final after
that and there might also be another beta between now and the final
release if that turns out to be necessary (I hope it won't).

So we'd like to propose that the RC7 which was released last week will
be released as the official 2.8 beta by Friday this week. If people
strongly disagree because they think some critical functionality is
missing, they should please speak up between now and Thursday. But we
should keep in mind that every new RC extracts a price -- it has to be
prepared and then a lot of software has to be re-tested against it. So
it's a non-trivial commitment of time by quite a few people.

We also decided that the Eclipse IDE will be released concurrently
with the 2.8 beta but would be built against the latest trunk rather
than the RC7. Generally, the Eclipse IDE will follow its own release
schedule in the future, probably with more frequent updates than the
release itself. As such it's just like the Netbeans and IntelliJ IDEs
which are also not synchronized.

For our internal 44,000 line Scala versioned asset management system, I'm slowly moving up the stack cutting code over to 2.8, it's been a good amount of work.

I've converted Scala Migrations, Scala Guava and our internal Scala common package to 2.8.  I now need a port of Kestrel to 2.8 and then I can finally do the main application.

What I've noticed so far is

1) No Java wrappers for java.util.concurrent.ConcurrentMap.  The putIfAbsent() method is the most important one for us.  Looking at the code, I see JMapWrapper is a case class and it would be good to extend this class to share functionality for a JConconcurrentMapWrapper, but extending case classes with another case class is deprecated now.

2) No Java wrappers for java.util.Hashtable which is the superclass to java.util.Properties.  Right now to iterate over elements I need to do something like JavaConversions.asSet(props.entrySet), not too bad.

Regards,
Blair

--
Daniel C. Sobral

I travel to the future all the time.

Thanks, don't know why I didn't notice that before. Maybe because in
2.7.x we have a scala.collections.jcl.Hashtable wrapper.

Blair

On 01/13/2010 10:35 AM, Daniel Sobral wrote:
> Not HashTable, no, but Map (which is implemented by Properties), yes. See
> http://stackoverflow.com/questions/2016268/getting-a-scala-map-from-a-ja...
>
> On Wed, Jan 13, 2010 at 4:13 PM, Blair Zajac > wrote: