Why Scala 2.8 instead of Scala 3.0?

On Mon, Oct 19, 2009 at 3:48 AM, Alex Blewitt <alex [dot] blewitt [at] gmail [dot] com> wrote:

Given the size of the changes between 2.7 and the proposed 2.8, coupled with the fact that 2.8 is now binary incompatible with 2.7, what is the reason for not following accepted version numbering wisdom and bumping the major version to indicate a backward incompatible change? Why are we targetting 'Scala 2.8' as the next version instead of 'Scala 3.0' ? If, as it is to be believed, that this is the last of the binary incompatible changes, then starting off with a new Scala 3.x prefix would make sense, and also give some kind of encouragement that the on-going debate on whether Scala is enterprise ready or not.

I couldn't agree more. And I really hope this will be the last time a new version is binary incompatible.

I fully agree!

2009/10/19 Alex Blewitt <alex [dot] blewitt [at] gmail [dot] com>

Given the size of the changes between 2.7 and the proposed 2.8, coupled with the fact that 2.8 is now binary incompatible with 2.7, what is the reason for not following accepted version numbering wisdom and bumping the major version to indicate a backward incompatible change? Why are we targetting 'Scala 2.8' as the next version instead of 'Scala 3.0' ? If, as it is to be believed, that this is the last of the binary incompatible changes, then starting off with a new Scala 3.x prefix would make sense, and also give some kind of encouragement that the on-going debate on whether Scala is enterprise ready or not.

Alex

Heiko

--

My job: weiglewilczek.com
My blog: heikoseeberger.name
Follow me: twitter.com/hseeberger
OSGi on Scala: scalamodules.org
Lift, the simply functional web framework: liftweb.net

I think we need a marketing push as well.

I propose:

Scala 3000 Cloud Edition
- A New Paradigm

On Mon, Oct 19, 2009 at 2:41 PM, Heiko Seeberger <heiko [dot] seeberger [at] googlemail [dot] com> wrote:

I fully agree!

2009/10/19 Alex Blewitt <alex [dot] blewitt [at] gmail [dot] com>

Given the size of the changes between 2.7 and the proposed 2.8, coupled with the fact that 2.8 is now binary incompatible with 2.7, what is the reason for not following accepted version numbering wisdom and bumping the major version to indicate a backward incompatible change? Why are we targetting 'Scala 2.8' as the next version instead of 'Scala 3.0' ? If, as it is to be believed, that this is the last of the binary incompatible changes, then starting off with a new Scala 3.x prefix would make sense, and also give some kind of encouragement that the on-going debate on whether Scala is enterprise ready or not.

Alex

Heiko

--

My job: weiglewilczek.com
My blog: heikoseeberger.name
Follow me: twitter.com/hseeberger
OSGi on Scala: scalamodules.org
Lift, the simply functional web framework: liftweb.net

--
Viktor Klang

Blog: klangism.blogspot.com
Twttr: viktorklang
Wave: viktor [dot] klang [at] googlewave [dot] com
Code: github.com/viktorklang

AKKA Committer - akkasource.org
Lift Committer - liftweb.com
Atmosphere Committer - atmosphere.dev.java.net
SoftPub founder: http://groups.google.com/group/softpub

Nils Kilden-Pedersen wrote:
> I couldn't agree more. And I really hope this will be the last time a
> new version is binary incompatible.

Highly unlikely as Scala traits are inherently binary incompatible when adding methods.

/Jesper Nordenberg

On Mon, Oct 19, 2009 at 16:29, Nils Kilden-Pedersen wrote:
> On Mon, Oct 19, 2009 at 3:48 AM, Alex Blewitt
> wrote:
>>
>> Given the size of the changes between 2.7 and the proposed 2.8, coupled
>> with the fact that 2.8 is now binary incompatible with 2.7, what is the
>> reason for not following accepted version numbering wisdom and bumping the
>> major version to indicate a backward incompatible change? Why are we
>> targetting 'Scala 2.8' as the next version instead of 'Scala 3.0' ? If, as
>> it is to be believed, that this is the last of the binary incompatible
>> changes, then starting off with a new Scala 3.x prefix would make sense, and
>> also give some kind of encouragement that the on-going debate on whether
>> Scala is enterprise ready or not.
>
> I couldn't agree more. And I really hope this will be the last time a new
> version is binary incompatible.

I think it's hard to make each subsequent version of Scala binary
compatible with previous. Because JVM bytecode is not flexible enough:
for example, you pull method from one interface to upper, and binary
compatibility breaks.

BTW, c++ does not almost allow binary compatibility. However it is
enterprise ready.

I hope, that Scala major releases (2.8 -> 2.9) will happen less
frequently, and be more stable and deliberate.

S.

On Mon, Oct 19, 2009 at 7:49 AM, Jesper Nordenberg <megagurka [at] yahoo [dot] com> wrote:

Nils Kilden-Pedersen wrote:
> I couldn't agree more. And I really hope this will be the last time a
> new version is binary incompatible.

Highly unlikely as Scala traits are inherently binary incompatible when adding methods.

Naturally, I mean to the same extent Java releases are binary compatible, i.e. backwards.
As it stands now, something compiled against 2.7 won't run on the 2.8 release. That's understandable considering what needs to get done, but it's not sustainable for Scala long term.

Adding methods to existing traits (or Java interfaces) vs. making new ones, is a design trade-off. The JVM is agnostic so long the new methods aren't called or are called conditionally. So if handled properly, it can be backwards compatible. It's been done in the JDK a few times.

On 19/10/2009 14:45, Viktor Klang wrote:

> Scala 3000 Cloud Edition
> - A New Paradigm

Viktor, I think you have a winner here, I'm already seeing the trailer
with space ships, and lasers, and so on. So bad it's for a computer
language ;)

Previous discussion on the subject can be found here:

http://comments.gmane.org/gmane.comp.lang.scala.internals/883

The basic conclusions seem to be that:
- version 2.8 had been heavily publicised, and was already mentioned in print
- It wasn't yet "well-rounded" enough to justify becoming 3.0

I'm guessing 3.0 is what will happen when all the knock-on effects of
2.8 collections have been sorted.

On Mon, Oct 19, 2009 at 2:14 PM, Francois wrote:
> On 19/10/2009 14:45, Viktor Klang wrote:
>
>> Scala 3000 Cloud Edition
>> - A New Paradigm
>
> Viktor, I think you have a winner here, I'm already seeing the trailer with
> space ships, and lasers, and so on. So bad it's for a computer language ;)
>

> Nils Kilden-Pedersen wrote:
> Adding methods to existing traits (or Java interfaces) vs.
> making new ones, is a design trade-off. The JVM is agnostic
> so long the new methods aren't called or are called
> conditionally. So if handled properly, it can be backwards
> compatible. It's been done in the JDK a few times.

Maybe I should clarify, the problem is more subtle with traits because even if you add a non-abstract method to a trait you're breaking binary compatibility (the consequence is that new code wont be able to call the method on objects created in old code). This is not the case with classes (abstract or not).

/Jesper Nordenberg

On Mon, Oct 19, 2009 at 8:37 AM, Jesper Nordenberg <megagurka [at] yahoo [dot] com> wrote:

> Nils Kilden-Pedersen wrote:
> Adding methods to existing traits (or Java interfaces) vs.
> making new ones, is a design trade-off. The JVM is agnostic
> so long the new methods aren't called or are called
> conditionally. So if handled properly, it can be backwards
> compatible. It's been done in the JDK a few times.

Maybe I should clarify, the problem is more subtle with traits because even if you add a non-abstract method to a trait you're breaking binary compatibility (the consequence is that new code wont be able to call the method on objects created in old code). This is not the case with classes (abstract or not).

How is that different, in substance, from what I wrote?

Nils Kilden-Pedersen wrote:
> How is that different, in substance, from what I wrote?

It isn't, but the binary incompatibility issue for traits is merely an implementation detail that's easy to overlook and get the impression that the same rules apply as for non-abstract class methods.

/Jesper Nordenberg

Scala is binary incompatible between releases, and (barring a major effort) will continue to be so.

This applies to -all- releases, even point releases. If it appears that 2.7.x is binary backwards compatible with 2.7.y (where y < x), then it's only because you haven't found the corner case that makes everything blow up. Trust me, I did most of the Scala-compatibility work for Lift for new 2.7.x releases. Lift depends on several Scala libraries (Specs, ScalaCheck). Trying to compile Lift with versions of Specs or ScalaCheck that weren't compiled against the same version of Scala was a disaster.

Let me repeat this as firmly as I can: SCALA IS BINARY INCOMPATIBLE. Any appearances to the contrary are an illusion.

Unless a MAJOR effort goes into addressing this, this will continue to be true even after 2.8.

AFAIK, the only backwards compatibility promise that 2.8 makes is that major breaking -source- changes will be much rarer.

--j

On Mon, Oct 19, 2009 at 1:48 AM, Alex Blewitt <alex [dot] blewitt [at] gmail [dot] com> wrote:

Given the size of the changes between 2.7 and the proposed 2.8, coupled with the fact that 2.8 is now binary incompatible with 2.7, what is the reason for not following accepted version numbering wisdom and bumping the major version to indicate a backward incompatible change? Why are we targetting 'Scala 2.8' as the next version instead of 'Scala 3.0' ? If, as it is to be believed, that this is the last of the binary incompatible changes, then starting off with a new Scala 3.x prefix would make sense, and also give some kind of encouragement that the on-going debate on whether Scala is enterprise ready or not.

Alex

We keep to the name 2.8 mainly because it was announced that way for
some time. Switching to 3.0 now would cause confusion.

On Mon, Oct 19, 2009 at 7:14 PM, Jorge Ortiz wrote:
> Scala is binary incompatible between releases, and (barring a major effort)
> will continue to be so.
>
I agree it will be a major effort but we are committed to do it. The
intention is that minor releases after 2.8 should be binary
migratable, and we will invest in healing class loaders and byte-code
rewriters to make this possible. Maybe, just maybe interface injection
in future VMs will make this redudant, but for the moment this is not
on the table.

Cheers

On Mon, Oct 19, 2009 at 11:11 AM, martin odersky <martin [dot] odersky [at] epfl [dot] ch> wrote:

We keep to the name 2.8 mainly because it was announced that way for
some time. Switching to 3.0 now would cause confusion.

On Mon, Oct 19, 2009 at 7:14 PM, Jorge Ortiz <jorge [dot] ortiz [at] gmail [dot] com> wrote:
> Scala is binary incompatible between releases, and (barring a major effort)
> will continue to be so.
>
I agree it will be a major effort but we are committed to do it. The
intention is that minor releases after 2.8 should be binary
migratable, and we will invest in healing class loaders and byte-code
rewriters to make this possible. Maybe, just maybe interface injection
in future VMs will make this redudant, but for the moment this is not
on the table.

FWIW, I have a design that does not require any run-time alteration of byte-code and supports migration of methods to different levels of a trait.  If I get some time, I'll write it up.
 

Cheers

On 19 Oct 2009, at 19:11, martin odersky wrote:

> We keep to the name 2.8 mainly because it was announced that way for
> some time. Switching to 3.0 now would cause confusion.

It will confuse more people that 2.7 and 2.8 are binary incompatible
than it would be to have an as-yet, not available product be
reversioned 3.0 to indicate the significance of the backward
compatibility break. Otherwise future minor releases (like 2.9) cannot
be relied upon to be compatible either.

In any case, there's no real reason to not choose a version number
that's more appropriate; after all, many products start out as x.y->x.y
+1, but having discovered that backward compatibility is broken, go to
x+1.0. No-one is confused by this. I also doubt that despite working
on a code-named 2.8 release that anyone would be surprised if a 3.0
was released instead.

There are other issues, particularly with traits, that may introduce
backward incompatible changes with the way that they're currently
implemented, but on the other hand, one can also build backward
incompatible Java classes as well, by removing interface methods, for
example. Thus, it is a matter of 'simple programming' to avoid such
problems, or follow good procedures (e.g. Eclipse's evolution of
classes) to ensure this doesn't happen. Whether this is more likely to
happen with Scala, due to its traits, shouldn't really be the problem.

In my opinion, source level compatibility isn't nearly as useful as
binary compatibility. If we're going to cut a line in the past, and
say that going forward, we're going to use The One True Way, then we
should do it by using a version that indicates a break from the past
rather than holding to a particular constraint because of some
previously announced message.

Can we have a vote on this mailing list as to the number of people
that would be confused if Scala 2.8 was called Scala 3.0 instead?

Alex

Alex, it might confuse people new to Scala, which, I admit, is thankfully most of them. But this situation isn't really new at all with Scala -- the same can be said of previous minor revisions.   I think providing binary compatibility between minor releases will be a feat in itself worthy of a major revision.   All that notwithstanding, I agree that too much has been said and printed about Scala 2.8 to, at this point, change it to Scala 3.0.

On Mon, Oct 19, 2009 at 4:34 PM, Alex Blewitt <alex [dot] blewitt [at] gmail [dot] com> wrote:

On 19 Oct 2009, at 19:11, martin odersky wrote:

We keep to the name 2.8 mainly because it was announced that way for
some time. Switching to 3.0 now would cause confusion.

It will confuse more people that 2.7 and 2.8 are binary incompatible than it would be to have an as-yet, not available product be reversioned 3.0 to indicate the significance of the backward compatibility break. Otherwise future minor releases (like 2.9) cannot be relied upon to be compatible either.

In any case, there's no real reason to not choose a version number that's more appropriate; after all, many products start out as x.y->x.y+1, but having discovered that backward compatibility is broken, go to x+1.0. No-one is confused by this. I also doubt that despite working on a code-named 2.8 release that anyone would be surprised if a 3.0 was released instead.

There are other issues, particularly with traits, that may introduce backward incompatible changes with the way that they're currently implemented, but on the other hand, one can also build backward incompatible Java classes as well, by removing interface methods, for example. Thus, it is a matter of 'simple programming' to avoid such problems, or follow good procedures (e.g. Eclipse's evolution of classes) to ensure this doesn't happen. Whether this is more likely to happen with Scala, due to its traits, shouldn't really be the problem.

In my opinion, source level compatibility isn't nearly as useful as binary compatibility. If we're going to cut a line in the past, and say that going forward, we're going to use The One True Way, then we should do it by using a version that indicates a break from the past rather than holding to a particular constraint because of some previously announced message.

Can we have a vote on this mailing list as to the number of people that would be confused if Scala 2.8 was called Scala 3.0 instead?

Alex

--
Daniel C. Sobral

Something I learned in academia: there are three kinds of academic reviews: review by name, review by reference and review by value.

On 19 Oct 2009, at 19:57, Daniel Sobral wrote:

> Alex, it might confuse people new to Scala, which, I admit, is
> thankfully most of them. But this situation isn't really new at all
> with Scala -- the same can be said of previous minor revisions.

That it might be confusing for people who haven't used it before is
not exactly the target market for the nomenclature. It is those who
have (or will have) expectations about the release process, or lack
thereof, and will therefore tend to avoid using Scala as a serious
language in the future. So you're not just hurting people who haven't
used Scala before, you're also discouraging them from wanting to use
it in the future, either.

> All that notwithstanding, I agree that too much has been said and
> printed about Scala 2.8 to, at this point, change it to Scala 3.0.

I'm sorry; the existence of e-mails using the term 'Scala 2.8' to
discuss a not-yet released language should be not be used as
conclusive proof that the renaming does not make sense. In any case,
the mark of intelligence is not sticking by dogma that has been
printed in the past, but rather evaluating the situation as more
information becomes available and then using that to adjust one's
position. In this case, we have on the one hand a term which exists
electronically and on the other hand, well-established software
procedures relating to the backwards compatibility (or lack thereof)
in version numbering products.

Or are we doomed to ever walk the follies of Java 1.x, whose initial
digit is wedded to unity regardless of the content?

Alex

On Oct 19, 2009, at 2:57 PM, Daniel Sobral wrote:
> Alex, it might confuse people new to Scala, which, I admit, is
> thankfully most of them. But this situation isn't really new at all
> with Scala -- the same can be said of previous minor revisions.
>
> I think providing binary compatibility between minor releases will
> be a feat in itself worthy of a major revision.

You beat me to it.

> All that notwithstanding, I agree that too much has been said and
> printed about Scala 2.8 to, at this point, change it to Scala 3.0.

An even stronger argument.

In more detail, it's always been the case that new minor versions
usually break binary compatibility. They often break source
compatibility, but never in any major way that I can remember for the
2.x series. Indeed, I think of 2.x as the cutoff where backwards
compatibility of any kind became very important. It hasn't been
perfect, but at least it's close.

That said, it's wonderful news if 2.8 is anywhere close to binary
compatible with 2.7. Very nice work!

Stepping back, version numbers are for marketing, and they provide a
very narrow stream of information you can convey with it. It's
important that that information corresponds to the most important
story you want to tell Scala users. Especially this is the case for
3.0.

I don't know what 3.x should correspond to, but I bet if you guys take
some time you will come up with something more important to you than
anything to do with compatibility. Lots of people will go check out
what's new with Scala whenever you announce a 3.0 version. It's also
very helpful when you bump into people and have 15 second to explain
new Scala developments. I bet there's a definition of 3.x that gets
people pumped even with just 15 seconds to explain it.

By the way, I agree that Java numbering is nearly information free.
It's not even just the useless leading "1". 1.5 is vastly different
from 1.4, but it got hte same sized bump as 1.1 through 1.4. 1.6 is
really minor in comparison, but it got an equal-sized version bump.
1.7 doesn't make any major change, per se, but it looks likely to
include piles of new features, much of which come from outside of
Sun. On top of it all, "Java 2" is floating around, even though none
of the versions have a "2" in them. The most charitable way I can
defend this situation is that Sun is better off when people can't tell
the difference between Java versions. Perhaps Sun's real message is
that all of Java is about the same.

> Something I learned in academia: there are three kinds of academic
> reviews: review by name, review by reference and review by value.

Awesome.

Lex