Release numbering

Release numbering

[Richard Kenner]

I'd like to re-raise the issue of whether the next release should be
3.5 or 4.0.

There seems to be a fundamental disagreement here as to numberings.

Despite Mark just saying that "The tree-ssa changes are a huge perturbation",
he doesn't feel it's large enough to justify a move to 4.0 due to not having
enough user-visible changes.  A large number of other people on this list
agree with that view.

Others, including me, Robert Dewar and a different large number of people
on the list, feel that the internal changes are enough to justify the
version number change because we want to give users notice that this is
a major change.  The change in Fortran is also a large user-visible change.

We've been through this discussion on the list a number of times and have
not come to any conclusion.  I doubt we can, so I'm not suggesting we
start discussion on this size list.

However, I believe that this is a large enough issue that it should be
raised before the entire SC and see what conclusions they come to.
So I'd like to request that the SC take up this issue.

Re: Release numbering

[Phil Edwards]

On Sun, Aug 29, 2004 at 09:12:44PM -0400, Richard Kenner wrote:
> Despite Mark just saying that "The tree-ssa changes are a huge perturbation",
> he doesn't feel it's large enough to justify a move to 4.0 due to not having
> enough user-visible changes.  A large number of other people on this list
> agree with that view.

It's more than that.  We're still often slower, we're still often buggier,
we're still cleaning up from the results of (a very successful) merge.

It's not always better than 3.0.


Let me put it like this:  there are people who feel that /no/ change to the
major version will ever be appropriate.  Many of us feel that it /would/
be appropriate if we reached a few more prerequisites.  Once they're
reached, we agree with that 4.0 would be appropriate, and eventually --
not too far off -- there will be a large majority consensus for 4.0.

Trying to get the SC to hand down a 4.0 decision now will cause tension,
fights, disagreement, plagues, etc.  Why not work together to create a
release that we can agree is worthy of the name 4.0?  Why does it have to
be forced through now?


-- 
Behind everything some further thing is found, forever; thus the tree behind
the bird, stone beneath soil, the sun behind Urth.  Behind our efforts, let
there be found our efforts.
              - Ascian saying, as related by Loyal to the Group of Seventeen

Re: Release numbering

[Gabriel Dos Reis]

Phil Edwards <phil@codesourcery.com> writes:

[...]

| Trying to get the SC to hand down a 4.0 decision now will cause tension,
| fights, disagreement, plagues, etc.  Why not work together to create a
| release that we can agree is worthy of the name 4.0?

Some people are of the opinion that we've reached the point where we
can name it 4.0.  And they are working together with other GCC
developers too, on the same product.

-- Gaby

Re: Release numbering

[Gabriel Dos Reis]

kenner@vlsi1.ultra.nyu.edu (Richard Kenner) writes:

| I'd like to re-raise the issue of whether the next release should be
| 3.5 or 4.0.
| 
| There seems to be a fundamental disagreement here as to numberings.
| 
| Despite Mark just saying that "The tree-ssa changes are a huge perturbation",
| he doesn't feel it's large enough to justify a move to 4.0 due to not having
| enough user-visible changes.

I must confess that I got quite confused by the other mail.  I believe
we should take a consistent approach to the tree-ssa merge.  It can't
be said that is a huge pertubation -- one that is disruptive in the
sense that it causes huge projects going on and disagreements about
developers about when to branch -- and at the same hold that it does
not justify a new major release numbering. 

| A large number of other people on this list
| agree with that view.
| 
| Others, including me, Robert Dewar and a different large number of people
| on the list, feel that the internal changes are enough to justify the
| version number change because we want to give users notice that this is
| a major change.  The change in Fortran is also a large user-visible change.

Agreed.

| We've been through this discussion on the list a number of times and have
| not come to any conclusion.  I doubt we can, so I'm not suggesting we
| start discussion on this size list.
| 
| However, I believe that this is a large enough issue that it should be
| raised before the entire SC and see what conclusions they come to.

It is voting time?  If yes, I vote [yes] to call the next major release 4.0.

| So I'd like to request that the SC take up this issue.

-- Gaby

Re: Release numbering

[Phil Edwards]

Consider this, friends:

Occasionally one of us developers has made a suggestion that many other
people like, but is just too large a change.  Throwing out specs for
something simpler, using caret diagnostics by default, running daemonized
versions of tools; these are just three I can remember off the top of
my head.  Dozens have been proposed over the years.  

These tend to not happen for a lot of reasons, but maintaining compatability
is usually the most important of those reasons.  Users expect to be able to
replace/augment specs with 3.x; users of emacs and wily and heaven knows
how many other tools which parse our error messages expect that random
punctuation like carets to not appear; users don't expect the compiler to
stay resident in memory without being told to do so.

Users expect 3.(x+1) to behave mostly the same as 3.x did.  They will be
surprised if there are major changes.

Users will expect 4.1 to behave much the same as 4.0, and they'll expect
4.2 to be like 4.1 but with improvements, etc.  They will be surprised if
there are major changes.

Users will not expect a 4.0 release to behave like a 3.x release.
I'm certainly not saying it /shouldn't/ behave the same; there's no need
to gratuitously make thihgs different.  But users will not be surprised if
they differ.  They expect to conditionalize their scripts and makefiles
and other programs on major version numbers of /any/ tool, and GCC is
viewed no differently.  That's an opportunity we should not discard.

Here's my point:

    We need to hold the 4.0 label in reserve for Big Incompatible Changes.
    Not just "user-visible" ones, although they clearly would play a part.
    But any change where the users /must/ know whether 3.x or 4.x is in
    use before they (or their tools) can get much farther, /those/ are
    what we should wait for before changing the major version.

The 3.5 code is supposed to be starting to stabilize for release.  Now is
clearly not the time to, for example, completely change the formatting
of our diagnostic output.  But if we release 3.5 as 4.0, then the Big
Incompatible Changes are going to have to wait until 5.0 to go in.


Phil

-- 
"This release is mostly intended to mop up the minor and trivial bug fixes
in the list and clear out the documentation changes.  As such, it should be
treated with even more suspicion than is normal."
    - dpkg 1.10.22 release note

Re: Release numbering

[Gabriel Dos Reis]

Phil Edwards <phil@codesourcery.com> writes:

Hi,

[...]

| Here's my point:
| 
|     We need to hold the 4.0 label in reserve for Big Incompatible Changes.
|     Not just "user-visible" ones, although they clearly would play a part.
|     But any change where the users /must/ know whether 3.x or 4.x is in
|     use before they (or their tools) can get much farther, /those/ are
|     what we should wait for before changing the major version.
| 
| The 3.5 code is supposed to be starting to stabilize for release.  Now is
| clearly not the time to, for example, completely change the formatting
| of our diagnostic output.  But if we release 3.5 as 4.0, then the Big
| Incompatible Changes are going to have to wait until 5.0 to go in.

Or 6.0. Or whatever.  We never sworn carret diagnostics for 4.0.
Not just because we can't implement carret diagnostics now means we
should not reject the "huge perturbation" in the next release.

"Big Incompatible Changes" can happen several times; we need not wait
for all of them happening for 4.0, just like we would not "wait until
it is ready" before branching.

-- Gaby

Re: Release numbering

[Laurent GUERBY]

On Mon, 2004-08-30 at 05:18, Gabriel Dos Reis wrote:
> It is voting time?  If yes, I vote [yes] to call the next major release 4.0.

<aol>me too</aol>

Laurent

Re: Release numbering

[Robert Dewar]

Phil Edwards wrote:

> Trying to get the SC to hand down a 4.0 decision now will cause tension,
> fights, disagreement, plagues, etc.  Why not work together to create a
> release that we can agree is worthy of the name 4.0?  Why does it have to
> be forced through now?

A major version number is not a medal for achievment!

It is simply an indication of a significant change in the technology
that warns users that the change is not a simple incremental one, and
indeed is one that may cause issues of performance and realiability
at first, and therefore some people may legitimately hesitate to move
to the new major release, or at least to the first minor release under
this major release.

If I am a user of software and I see the version number change from
3.4 to 3.5, I assume this is an incremental release which can be
expected to be an improvement without major regressions.

If I see a change from 3.4 to 4.0, I know a big change has taken
place.

> It's more than that.  We're still often slower, we're still often buggier,
> we're still cleaning up from the results of (a very successful) merge.

That's an argument *for* a major version number change, not against.

Re: Release numbering

[David Edelsohn]

>>>>> Phil Edwards writes:

Phil> Users expect 3.(x+1) to behave mostly the same as 3.x did.  They will be
Phil> surprised if there are major changes.

Phil> We need to hold the 4.0 label in reserve for Big Incompatible Changes.
Phil> Not just "user-visible" ones, although they clearly would play a part.
Phil> But any change where the users /must/ know whether 3.x or 4.x is in
Phil> use before they (or their tools) can get much farther, /those/ are
Phil> what we should wait for before changing the major version.

	We can change the GCC version to 4.0 the next time libstdc++ is
rewritten or stabilizes, which ever comes first. 1/2 :-)

David

Re: Release numbering

[Joseph S. Myers]

On Mon, 30 Aug 2004, Gabriel Dos Reis wrote:

> Or 6.0. Or whatever.  We never sworn carret diagnostics for 4.0.
> Not just because we can't implement carret diagnostics now means we
> should not reject the "huge perturbation" in the next release.

We can also implement them incrementally under -Wcaret (say) and improve 
the precision of the location information passed to diagnostic functions, 
message by message, to make them more useful.  (After adding testsuite 
support for testing the precise character at which a diagnostic is given.)  
No need to avoid implementing something because of version numbers if the 
usual principles of incremental development and avoiding big incompatible 
changes are followed.  Changing the default, if desired, would be an 
incompatible change, but one only needing -Wno-caret added to tools 
parsing output, and there would probably have been a few releases in which 
the -Wno-caret option existed but was the default, serving as due warning 
to tool maintainers, before any such change.

I believe in incremental improvement and avoiding big incompatible 
changes.

I don't care about whether the version number is 3.5 or 4.0 or 5 or 2005 
or any other variation someone wants to invent, as long as the version 
numbers stay monotonic increasing.

-- 
Joseph S. Myers               http://www.srcf.ucam.org/~jsm28/gcc/
  http://www.srcf.ucam.org/~jsm28/gcc/#c90status - status of C90 for GCC 3.5
    jsm@polyomino.org.uk (personal mail)
    jsm28@gcc.gnu.org (Bugzilla assignments and CCs)

Re: Release numbering

[Phil Edwards]

On Mon, Aug 30, 2004 at 06:08:09PM +0000, Joseph S. Myers wrote:
> I don't care about whether the version number is 3.5 or 4.0 or 5 or 2005 
> or any other variation someone wants to invent, as long as the version 
> numbers stay monotonic increasing.

We could use code names, like Debian borrowing characters from the "Toy
Story" movie series.

For GCC, I suggest names from "Boondock Saints".

-- 
Behind everything some further thing is found, forever; thus the tree behind
the bird, stone beneath soil, the sun behind Urth.  Behind our efforts, let
there be found our efforts.
              - Ascian saying, as related by Loyal to the Group of Seventeen

Re: Release numbering

[Per Bothner]

Gabriel Dos Reis wrote:

> Or 6.0. Or whatever.  We never sworn carret diagnostics for 4.0.

It doesn't seem anyone really cares much about caret diagnostics.
At least I haven't seen a lot of help with --enable-mapped-location.

As a start, if somebody could test and fix regressions for c and c++,
and make sure it works for objc, it would free me to work on other
languages.  (Fortran looks easy, by the way.)
-- 
	--Per Bothner
per@bothner.com   http://per.bothner.com/

Re: Release numbering

[Zack Weinberg]

Per Bothner <per@bothner.com> writes:

> Gabriel Dos Reis wrote:
>
>> Or 6.0. Or whatever.  We never sworn carret diagnostics for 4.0.
>
> It doesn't seem anyone really cares much about caret diagnostics.
> At least I haven't seen a lot of help with --enable-mapped-location.
>
> As a start, if somebody could test and fix regressions for c and c++,
> and make sure it works for objc, it would free me to work on other
> languages.  (Fortran looks easy, by the way.)

I'm banging around in the C++ parser right now, so I'll try to
investigate the regressions later this week.

zw

Re: Release numbering [--enable-mapped-location]

[Per Bothner]

Zack Weinberg wrote:

> I'm banging around in the C++ parser right now, so I'll try to
> investigate the regressions later this week.

Thanks.  Last I looked there was only one "cluster" of pch-related
regressions, but I wouldn't be surprised if something had broken since.

Could somebody take a look at objc - I don't know any reason it
shouldn't work, but I have tested it ...
-- 
	--Per Bothner
per@bothner.com   http://per.bothner.com/

Re: Release numbering

[Joseph S. Myers]

On Mon, 30 Aug 2004, Per Bothner wrote:

> It doesn't seem anyone really cares much about caret diagnostics.
> At least I haven't seen a lot of help with --enable-mapped-location.

After all, GCC developers are experts at working out what on a source line 
GCC's diagnostics are referring to, making caret diagnostics excess 
verbosity much of the time.

I'd see --enable-mapped-location as of clear importance in compile-time 
performance (including getting rid of TREE_COMPLEXITY as you noted in 
<http://gcc.gnu.org/ml/gcc-patches/2004-07/msg01798.html>) and general 
compiler cleanliness, as much for value in facilitating new features such 
as caret diagnostics.

I'd like to get rid of TREE_COMPLEXITY, clean up and speed up the 
compiler, etc.; the --enable-mapped-location changes to facilitate it just 
seemed too large and far off from the patch I was doing at the time to 
remove TREE_COMPLEXITY for C and C++ to go and start doing this work on 
the Java front end 
<http://gcc.gnu.org/ml/gcc-patches/2004-07/msg01879.html>.  So it was 
natural to presume that this work will probably be done better and quicker 
by those with more familiarity with the relevant parts of the compiler, 
and instead go on to projects on parts of the compiler with which I have 
greater familiarity, with an eye there too to possible performance and 
cleanliness improvements involved in the changes, and to such changes that 
might be possible afterwards consequentially, with a hope but no 
particular expectation of being able to make such subsequent improvements.

-- 
Joseph S. Myers               http://www.srcf.ucam.org/~jsm28/gcc/
  http://www.srcf.ucam.org/~jsm28/gcc/#c90status - status of C90 for GCC 3.5
    jsm@polyomino.org.uk (personal mail)
    jsm28@gcc.gnu.org (Bugzilla assignments and CCs)