Re: Why Scala 2.8 instead of Scala 3.0?

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.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

 -- Martin

> 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.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.
>>
>> Alex
>
>