This page is no longer maintained — Please continue to the home page at www.scala-lang.org

2.8 -> 3.0?

11 replies
odersky
Joined: 2008-07-29,
User offline. Last seen 45 weeks 6 days ago.

Hi all,

The recent discussion on package nesting seems to reach the conclusion
that we should modify the rules, and that we should accept the
backwards incompatibilies this would incur. I.e. if you wrote
previously

package x.y.z
...

members of the outer package x.y would be visible. Now, to get the
same effect, you'd have to write

package x.y
package z
...

I think this is a net improvement, because we will pull in a new scope
only by an explicit declaration, not silently by writing a path in a
package clause. But it is a backwards incompatibility. I was
wondering, therefore, whether we should call the upcoming version
Scala 3, instead of Scala 2.8.

Cheers

extempore
Joined: 2008-12-17,
User offline. Last seen 35 weeks 3 days ago.
Re: 2.8 -> 3.0?

On Sat, Jul 18, 2009 at 08:08:37PM +0200, martin odersky wrote:
> I think this is a net improvement, because we will pull in a new scope
> only by an explicit declaration, not silently by writing a path in a
> package clause. But it is a backwards incompatibility. I was
> wondering, therefore, whether we should call the upcoming version
> Scala 3, instead of Scala 2.8.

I would like to cast a vote against. My personal quality standards for
a "3" are a lot higher than for a "2.8", but nobody (including me) would
want to wait for my "3" standards to be met before releasing again.
There is so much new code in 2.8, I strongly feel we should anticipate
requiring a whole series of minor revisions just to reach 2.7 levels of
stability, let alone a hypothetical and desirable even higher level.

Whether it makes any sense or not, choice of version number ends up
having a huge impact on peoples' expectations.

DRMacIver
Joined: 2008-09-02,
User offline. Last seen 42 years 45 weeks ago.
Re: 2.8 -> 3.0?

2009/7/18 martin odersky :
> Hi all,
>
> The recent discussion on package nesting seems to reach the conclusion
> that we should modify the rules, and that we should accept the
> backwards incompatibilies this would incur. I.e. if you wrote
> previously
>
>  package x.y.z
>  ...
>
> members of the outer package x.y would be visible. Now, to get the
> same effect, you'd have to write
>
>  package x.y
>  package z
>  ...
>
> I think this is a net improvement, because we will pull in a new scope
> only by an explicit declaration, not silently by writing a path in a
> package clause. But it is a backwards incompatibility. I was
> wondering, therefore, whether we should call the upcoming version
> Scala 3, instead of Scala 2.8.

I agree with the sentiment that a version with this feature should be
called Scala 3.0. I think this might be more of a sign that it
shouldn't be in the next version than that the next version should be
3.0. There's already enough scary breaking stuff slated for 2.8, let's
not increase that.

Erik Engbrecht
Joined: 2008-12-19,
User offline. Last seen 3 years 18 weeks ago.
Re: 2.8 -> 3.0?
I've been thinking Scala 2.8.0 should really be 3.0 for a while.
I usually think of major revision numbers as indicating significant changes the indicate major breaks in backward compatibility, and when I major version is followed by a dot-zero I assume an increase in bugginess.  Minor revs, on the other hand, indicate much smaller breaks and a decline in bugginess.
So, based on the signals it sends to users, I think Paul's argument supports making 2.8 be 3.0.

On Sat, Jul 18, 2009 at 2:29 PM, Paul Phillips <paulp [at] improving [dot] org> wrote:

On Sat, Jul 18, 2009 at 08:08:37PM +0200, martin odersky wrote:
> I think this is a net improvement, because we will pull in a new scope
> only by an explicit declaration, not silently by writing a path in a
> package clause. But it is a backwards incompatibility. I was
> wondering, therefore, whether we should call the upcoming version
> Scala 3, instead of Scala 2.8.

I would like to cast a vote against.  My personal quality standards for
a "3" are a lot higher than for a "2.8", but nobody (including me) would
want to wait for my "3" standards to be met before releasing again.
There is so much new code in 2.8, I strongly feel we should anticipate
requiring a whole series of minor revisions just to reach 2.7 levels of
stability, let alone a hypothetical and desirable even higher level.

Whether it makes any sense or not, choice of version number ends up
having a huge impact on peoples' expectations.

--
Paul Phillips      | Appreciation is a wonderful thing; it makes what is
Protagonist        | excellent in others belong to us as well.
Empiricist         |     -- Voltaire
ha! spill, pupil   |----------* http://www.improving.org/paulp/ *----------



--
http://erikengbrecht.blogspot.com/
extempore
Joined: 2008-12-17,
User offline. Last seen 35 weeks 3 days ago.
Re: 2.8 -> 3.0?

On Sat, Jul 18, 2009 at 02:39:54PM -0400, Erik Engbrecht wrote:
> I've been thinking Scala 2.8.0 should really be 3.0 for a while. I
> usually think of major revision numbers as indicating significant
> changes the indicate major breaks in backward compatibility, and when
> I major version is followed by a dot-zero I assume an increase in
> bugginess. Minor revs, on the other hand, indicate much smaller breaks
> and a decline in bugginess.
>
> So, based on the signals it sends to users, I think Paul's argument
> supports making 2.8 be 3.0.

The problem is that there are multiple signals sent by a version number
which are not necessarily correlated.

You're right that 3.0 sends a much clearer "we are breaking
compatibility" message than does 2.8. I do not think this is
particularly important.

The choice of 3.0 also sends a "this is the release we have chosen as
our best foot forward for the scala 3 era" signal. There is an
expectation that we think it's pretty usable, that most of the bugs are
unknown. I do not see how this next release can meet that test.

But it's entirely possible my standards are not in line with the rest of
the world's.

Chris Twiner
Joined: 2008-12-17,
User offline. Last seen 42 years 45 weeks ago.
Re: 2.8 -> 3.0?

On Sat, Jul 18, 2009 at 8:49 PM, Paul Phillips wrote:
> On Sat, Jul 18, 2009 at 02:39:54PM -0400, Erik Engbrecht wrote:
>> I've been thinking Scala 2.8.0 should really be 3.0 for a while. I
>> usually think of major revision numbers as indicating significant
>> changes the indicate major breaks in backward compatibility, and when
>> I major version is followed by a dot-zero I assume an increase in
>> bugginess. Minor revs, on the other hand, indicate much smaller breaks
>> and a decline in bugginess.
>>
>> So, based on the signals it sends to users, I think Paul's argument
>> supports making 2.8 be 3.0.
>
> The problem is that there are multiple signals sent by a version number
> which are not necessarily correlated.
>
> You're right that 3.0 sends a much clearer "we are breaking
> compatibility" message than does 2.8.  I do not think this is
> particularly important.
>
> The choice of 3.0 also sends a "this is the release we have chosen as
> our best foot forward for the scala 3 era" signal.  There is an
> expectation that we think it's pretty usable, that most of the bugs are
> unknown.  I do not see how this next release can meet that test.
>
> But it's entirely possible my standards are not in line with the rest of
> the world's.
>

+1

For me the breaking changes have occurred on every version so far, at
the very least with regards to binary compatibility. I think it would
make sense for 3.0 to be the enterprise safe version, more a label of
stability and compatibility then for feature set.

Kevin Wright
Joined: 2009-06-09,
User offline. Last seen 49 weeks 3 days ago.
Re: 2.8 -> 3.0?
pros:It sends the right message that there are big changes (named + default args, collection library, package scoping)
cons:The world + dog has already been primed to expect 2.8 with big and possibly breaking changes in.  resetting the minor version number may send the message that this is a massive rewrite, relatively untested, and therefore risky.  We don't want that!

On Sat, Jul 18, 2009 at 7:49 PM, Paul Phillips <paulp [at] improving [dot] org> wrote:
On Sat, Jul 18, 2009 at 02:39:54PM -0400, Erik Engbrecht wrote:
> I've been thinking Scala 2.8.0 should really be 3.0 for a while. I
> usually think of major revision numbers as indicating significant
> changes the indicate major breaks in backward compatibility, and when
> I major version is followed by a dot-zero I assume an increase in
> bugginess. Minor revs, on the other hand, indicate much smaller breaks
> and a decline in bugginess.
>
> So, based on the signals it sends to users, I think Paul's argument
> supports making 2.8 be 3.0.

The problem is that there are multiple signals sent by a version number
which are not necessarily correlated.

You're right that 3.0 sends a much clearer "we are breaking
compatibility" message than does 2.8.  I do not think this is
particularly important.

The choice of 3.0 also sends a "this is the release we have chosen as
our best foot forward for the scala 3 era" signal.  There is an
expectation that we think it's pretty usable, that most of the bugs are
unknown.  I do not see how this next release can meet that test.

But it's entirely possible my standards are not in line with the rest of
the world's.

--
Paul Phillips      | Eschew mastication.
Moral Alien        |
Empiricist         |
pp: i haul pills   |----------* http://www.improving.org/paulp/ *----------

Erik Engbrecht
Joined: 2008-12-19,
User offline. Last seen 3 years 18 weeks ago.
Re: 2.8 -> 3.0?
Paul,I see your point, and I'm going to waffle...
The point David just made on IRC about needing more completeness in the standard library for a 3.0 release is completely true, along with other points being made as I type this....
-Erik
On Sat, Jul 18, 2009 at 2:49 PM, Paul Phillips <paulp [at] improving [dot] org> wrote:
On Sat, Jul 18, 2009 at 02:39:54PM -0400, Erik Engbrecht wrote:
> I've been thinking Scala 2.8.0 should really be 3.0 for a while. I
> usually think of major revision numbers as indicating significant
> changes the indicate major breaks in backward compatibility, and when
> I major version is followed by a dot-zero I assume an increase in
> bugginess. Minor revs, on the other hand, indicate much smaller breaks
> and a decline in bugginess.
>
> So, based on the signals it sends to users, I think Paul's argument
> supports making 2.8 be 3.0.

The problem is that there are multiple signals sent by a version number
which are not necessarily correlated.

You're right that 3.0 sends a much clearer "we are breaking
compatibility" message than does 2.8.  I do not think this is
particularly important.

The choice of 3.0 also sends a "this is the release we have chosen as
our best foot forward for the scala 3 era" signal.  There is an
expectation that we think it's pretty usable, that most of the bugs are
unknown.  I do not see how this next release can meet that test.

But it's entirely possible my standards are not in line with the rest of
the world's.

--
Paul Phillips      | Eschew mastication.
Moral Alien        |
Empiricist         |
pp: i haul pills   |----------* http://www.improving.org/paulp/ *----------



--
http://erikengbrecht.blogspot.com/
Erik Engbrecht
Joined: 2008-12-19,
User offline. Last seen 3 years 18 weeks ago.
Re: 2.8 -> 3.0?
cons:
The world + dog has already been primed to expect 2.8 with big and possibly breaking changes in.  resetting the minor version number may send the message that this is a massive rewrite, relatively untested, and therefore risky.  We don't want that!

I think if that's not to be the reality of the 2.8 release, then some really heavy testing and bug fixing is in order.
On Sat, Jul 18, 2009 at 3:01 PM, Kevin Wright <kev [dot] lee [dot] wright [at] googlemail [dot] com> wrote:
pros:It sends the right message that there are big changes (named + default args, collection library, package scoping)
cons:The world + dog has already been primed to expect 2.8 with big and possibly breaking changes in.  resetting the minor version number may send the message that this is a massive rewrite, relatively untested, and therefore risky.  We don't want that!

On Sat, Jul 18, 2009 at 7:49 PM, Paul Phillips <paulp [at] improving [dot] org> wrote:
On Sat, Jul 18, 2009 at 02:39:54PM -0400, Erik Engbrecht wrote:
> I've been thinking Scala 2.8.0 should really be 3.0 for a while. I
> usually think of major revision numbers as indicating significant
> changes the indicate major breaks in backward compatibility, and when
> I major version is followed by a dot-zero I assume an increase in
> bugginess. Minor revs, on the other hand, indicate much smaller breaks
> and a decline in bugginess.
>
> So, based on the signals it sends to users, I think Paul's argument
> supports making 2.8 be 3.0.

The problem is that there are multiple signals sent by a version number
which are not necessarily correlated.

You're right that 3.0 sends a much clearer "we are breaking
compatibility" message than does 2.8.  I do not think this is
particularly important.

The choice of 3.0 also sends a "this is the release we have chosen as
our best foot forward for the scala 3 era" signal.  There is an
expectation that we think it's pretty usable, that most of the bugs are
unknown.  I do not see how this next release can meet that test.

But it's entirely possible my standards are not in line with the rest of
the world's.

--
Paul Phillips      | Eschew mastication.
Moral Alien        |
Empiricist         |
pp: i haul pills   |----------* http://www.improving.org/paulp/ *----------




--
http://erikengbrecht.blogspot.com/
milessabin
Joined: 2008-08-11,
User offline. Last seen 33 weeks 3 days ago.
Re: 2.8 -> 3.0?

On Sat, Jul 18, 2009 at 7:08 PM, martin odersky wrote:
> The recent discussion on package nesting seems to reach the conclusion
> that we should modify the rules, and that we should accept the
> backwards incompatibilies this would incur. I.e. if you wrote
> previously
>
>  package x.y.z
>  ...
>
> members of the outer package x.y would be visible. Now, to get the
> same effect, you'd have to write
>
>  package x.y
>  package z
>  ...
>
> I think this is a net improvement, because we will pull in a new scope
> only by an explicit declaration, not silently by writing a path in a
> package clause.

Out of interest, what are your reasons for preferring this mechanism
over my suggestion of enhancing imports?

http://www.nabble.com/Re%3A-Nested-package-scopes-vs.-Imports-(Was%3A-Revisiting--absolute-relative-paths)-p24546471.html

Cheers,

Miles

Kevin Wright
Joined: 2009-06-09,
User offline. Last seen 49 weeks 3 days ago.
Re: 2.8 -> 3.0?
regarding miles' import change proposal...
The new package syntax looks as though it allows package declarations and imports to follow the same pattern.I like this idea, as I tend to think of them as reciprocal...
Hopefully, it's going to help adoption if we can combine some more of our idioms like this.

On Sat, Jul 18, 2009 at 7:59 PM, Miles Sabin <miles [at] milessabin [dot] com> wrote:
On Sat, Jul 18, 2009 at 7:08 PM, martin odersky<martin [dot] odersky [at] epfl [dot] ch> wrote:
> The recent discussion on package nesting seems to reach the conclusion
> that we should modify the rules, and that we should accept the
> backwards incompatibilies this would incur. I.e. if you wrote
> previously
>
>  package x.y.z
>  ...
>
> members of the outer package x.y would be visible. Now, to get the
> same effect, you'd have to write
>
>  package x.y
>  package z
>  ...
>
> I think this is a net improvement, because we will pull in a new scope
> only by an explicit declaration, not silently by writing a path in a
> package clause.

Out of interest, what are your reasons for preferring this mechanism
over my suggestion of enhancing imports?

http://www.nabble.com/Re%3A-Nested-package-scopes-vs.-Imports-(Was%3A-Revisiting--absolute-relative-paths)-p24546471.html

Cheers,


Miles

--
Miles Sabin
tel: +44 (0)7813 944 528
skype:  milessabin
http://www.chuusai.com/
http://twitter.com/milessabin

odersky
Joined: 2008-07-29,
User offline. Last seen 45 weeks 6 days ago.
Re: 2.8 -> 3.0?

>>
>> I think this is a net improvement, because we will pull in a new scope
>> only by an explicit declaration, not silently by writing a path in a
>> package clause.
>
> Out of interest, what are your reasons for preferring this mechanism
> over my suggestion of enhancing imports?
>
> http://www.nabble.com/Re%3A-Nested-package-scopes-vs.-Imports-(Was%3A-Revisiting--absolute-relative-paths)-p24546471.html
>
Mostly orthogonality. We already have that a single package clause

package p
...

is equivalent to

package p {
...
}

Now, if we go for the change in nested packages we have two possibilities:

- use several package clauses nested inside { ... }
- use generalized imports, which is different

But the obvious extension to keep non-brace syntax while nesting
packages is missing.
I must say, I appreciated the usefulness only after refactoring a
large part of the libraries. That's when I noticed how annoying the
imports are (and your proposed extension would not have helped in
these cases).

Cheers

Copyright © 2012 École Polytechnique Fédérale de Lausanne (EPFL), Lausanne, Switzerland