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.

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.

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@improving.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/

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.

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.

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@improving.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/ *----------

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@improving.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/

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.lee.wright@googlemail.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@improving.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/

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

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@milessabin.com> wrote:

On Sat, Jul 18, 2009 at 7:08 PM, martin odersky<martin.odersky@epfl.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

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