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