SC decision on version numbering: 4.0

SC decision on version numbering: 4.0

[Per Bothner]

The Steering Committee has decided that the the version number of
the next mainline-based tree-ssa-based release should be "4.0".
Some people preferred 3.95, but most preferred 4.0, finding
Robert Dewar's (http://gcc.gnu.org/ml/gcc/2004-08/msg01480.html)
argument compelling.
-- 
	--Per Bothner
per@bothner.com   http://per.bothner.com/

Re: SC decision on version numbering: 4.0

[Zack Weinberg]

Per Bothner <per@bothner.com> writes:

> The Steering Committee has decided that the the version number of
> the next mainline-based tree-ssa-based release should be "4.0".
> Some people preferred 3.95, but most preferred 4.0, finding
> Robert Dewar's (http://gcc.gnu.org/ml/gcc/2004-08/msg01480.html)
> argument compelling.

Let it be said that I still do not agree with this decision.  
I disapprove of any change to the major version number except when
there is no other alternative.  However, this is the last time I will
object to *this* increase of the major version number.

zw

Re: SC decision on version numbering: 4.0

[Mike Stump]

On Sep 9, 2004, at 11:41 AM, Per Bothner wrote:
> The Steering Committee has decided that the the version number of
> the next mainline-based tree-ssa-based release should be "4.0".
> Some people preferred 3.95, but most preferred 4.0, finding
> Robert Dewar's (http://gcc.gnu.org/ml/gcc/2004-08/msg01480.html)
> argument compelling.

Normally, I would just check this in...  but today, I shall ask for 
approval...


Ok?


Index: version.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/version.c,v
retrieving revision 1.2449
diff -u -p -u -r1.2449 version.c
--- version.c   9 Sep 2004 00:16:14 -0000       1.2449
+++ version.c   9 Sep 2004 21:27:10 -0000
@@ -5,7 +5,7 @@
     please modify this string to indicate that, e.g. by putting your
     organization's name in parentheses at the end of the string.  */

-const char version_string[] = "3.5.0 20040909 (experimental)";
+const char version_string[] = "4.0.0 20040909 (experimental)";

  /* This is the location of the online document giving instructions for
     reporting bugs.  If you distribute a modified version of GCC,

Re: SC decision on version numbering: 4.0

[Joseph S. Myers]

On Thu, 9 Sep 2004, Mike Stump wrote:

> Normally, I would just check this in...  but today, I shall ask for
> approval...

branching.html lists all the places that need changing for new major 
versions (mutatis mutandis for this case where the version number changes 
on mainline without an associated branch).  It is however out of date with 
regard to Gerald's changes to do snapshots from multiple branches; some 
special measures may be needed so that the first 4.0 snapshot has diffs 
from the last 3.5 one (and branching.html should document the applicable 
special measures).

-- 
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: SC decision on version numbering: 4.0

[Gabriel Dos Reis]

Mike Stump <mrs@apple.com> writes:

| On Sep 9, 2004, at 11:41 AM, Per Bothner wrote:
| > The Steering Committee has decided that the the version number of
| > the next mainline-based tree-ssa-based release should be "4.0".
| > Some people preferred 3.95, but most preferred 4.0, finding
| > Robert Dewar's (http://gcc.gnu.org/ml/gcc/2004-08/msg01480.html)
| > argument compelling.
| 
| Normally, I would just check this in...  but today, I shall ask for
| approval...
| 
| 
| Ok?

Does it fall under the obvious rule?

-- Gaby

Re: SC decision on version numbering: 4.0

[Robert Dewar]

Mike Stump wrote:

> On Sep 9, 2004, at 11:41 AM, Per Bothner wrote:
> 
>> The Steering Committee has decided that the the version number of
>> the next mainline-based tree-ssa-based release should be "4.0".
>> Some people preferred 3.95, but most preferred 4.0, finding
>> Robert Dewar's (http://gcc.gnu.org/ml/gcc/2004-08/msg01480.html)
>> argument compelling.
> 
> 
> Normally, I would just check this in...  but today, I shall ask for 
> approval...

Ah, does that have to be unanimous approval? :-)

Re: SC decision on version numbering: 4.0

[Gabriel Dos Reis]

Zack Weinberg <zack@codesourcery.com> writes:

| Per Bothner <per@bothner.com> writes:
| 
| > The Steering Committee has decided that the the version number of
| > the next mainline-based tree-ssa-based release should be "4.0".
| > Some people preferred 3.95, but most preferred 4.0, finding
| > Robert Dewar's (http://gcc.gnu.org/ml/gcc/2004-08/msg01480.html)
| > argument compelling.
| 
| Let it be said that I still do not agree with this decision.  
| I disapprove of any change to the major version number except when

At this stage, it is less an issue of approving or disapproving.
Mark had recently recalled the excellent point that, as RM for
mainline, he makes decisions and expects people to respect them.  I
guess that point holds for SC decisions too.

| there is no other alternative.  However, this is the last time I will
| object to *this* increase of the major version number.

-- Gaby

Re: SC decision on version numbering: 4.0

[Mark Mitchell]

Mike Stump wrote:

> On Sep 9, 2004, at 11:41 AM, Per Bothner wrote:
>
>> The Steering Committee has decided that the the version number of
>> the next mainline-based tree-ssa-based release should be "4.0".
>> Some people preferred 3.95, but most preferred 4.0, finding
>> Robert Dewar's (http://gcc.gnu.org/ml/gcc/2004-08/msg01480.html)
>> argument compelling.
>
>
> Normally, I would just check this in...  but today, I shall ask for 
> approval...

Yes, this is OK -- but please do work with Joseph/Gerald to make sure 
that any other issues that Joseph raised are dealt with.

-- 
Mark Mitchell
CodeSourcery, LLC
(916) 791-8304
mark@codesourcery.com

Re: SC decision on version numbering: 4.0

[Per Bothner]

Gabriel Dos Reis wrote:
> Zack Weinberg <zack@codesourcery.com> writes:
> | Let it be said that I still do not agree with this decision.  
> | I disapprove of any change to the major version number except when
> 
> At this stage, it is less an issue of approving or disapproving.
> Mark had recently recalled the excellent point that, as RM for
> mainline, he makes decisions and expects people to respect them.  I
> guess that point holds for SC decisions too.

I didn't read Zack's posting to imply anything else - just to
respectfully register his disagreement.

> | there is no other alternative.

It's hard to argue with that position, since it's hard to imagine
when "no other alternative" would be the case.

It's been suggested that 5.0 might be appropriate when we have
a really stable C++ ABI, including libstdc++ header files.  You
could make same condition for the in-progress Java "binary
compatible" ABI.
-- 
	--Per Bothner
per@bothner.com   http://per.bothner.com/

Re: SC decision on version numbering: 4.0

[Robert Dewar]

Per Bothner wrote:

> It's been suggested that 5.0 might be appropriate when we have
> a really stable C++ ABI, including libstdc++ header files.  You
> could make same condition for the in-progress Java "binary
> compatible" ABI.

Well to me, to repeat my earlier thoughts, that is completely
backward, as things stabilize, minor releases are appropriate.
A 5.0 release as a user says "unstable, major changes".

Re: SC decision on version numbering: 4.0

[Phil Edwards]

On Thu, Sep 09, 2004 at 03:15:26PM -0700, Per Bothner wrote:
> 
> It's been suggested that 5.0 might be appropriate when we have
> a really stable C++ ABI, including libstdc++ header files.  You
> could make same condition for the in-progress Java "binary
> compatible" ABI.

Even I would agree with bumping the major number at those points.  I was
kinda hoping we'd wait for the former for 4.0, but enh.  Integers are cheap.

-- 
AI.cpp:33241: warning: You wrote 'neurons.merge(solution1, solution2)",
AI.cpp:33241: you probably MEANT "neurons->merge(solution1, solution2)",
AI.cpp:33241: but there is a MUCH better way to implement this whole
AI.cpp:33241: function; doing that instead.

Re: SC decision on version numbering: 4.0

[Per Bothner]

Robert Dewar wrote:

> Well to me, to repeat my earlier thoughts, that is completely
> backward, as things stabilize, minor releases are appropriate.
> A 5.0 release as a user says "unstable, major changes".

The other reason for increasing a version number is for dynamic
shared library numbering.  If a new ABI is majorly incompatible
with the old one, then old libraries will be incompatible, so
it may be less confusing to bump major version numbers.  It's
a major change, but hopefully will be more-or-less stable.
If you prefer 5.0 could be "a stable ABI has been specified and
implemented" - it's *intended* to be stable, but there may be
minor bugs.
-- 
	--Per Bothner
per@bothner.com   http://per.bothner.com/

Re: SC decision on version numbering: 4.0

[Robert Dewar]

Per Bothner wrote:

> Robert Dewar wrote:
> 
>> Well to me, to repeat my earlier thoughts, that is completely
>> backward, as things stabilize, minor releases are appropriate.
>> A 5.0 release as a user says "unstable, major changes".
> 
> 
> The other reason for increasing a version number is for dynamic
> shared library numbering.  If a new ABI is majorly incompatible
> with the old one, then old libraries will be incompatible, so
> it may be less confusing to bump major version numbers.  It's
> a major change, but hopefully will be more-or-less stable.
> If you prefer 5.0 could be "a stable ABI has been specified and
> implemented" - it's *intended* to be stable, but there may be
> minor bugs.

OK, I agree that a *change* involving a majorly incompatible
ABI warrants a major version number change. Sorry I missed
that you were making this point.

Re: SC decision on version numbering: 4.0

[Mike Stump]

On Sep 9, 2004, at 2:48 PM, Joseph S. Myers wrote:
> branching.html lists all the places that need changing for new major
> versions

http://gcc.gnu.org/branching.html

	16.  	Update the email parsing script to handle bugs against the new 
versions. The script is in CVS at 
wwwdocs/bugzilla/contrib/bug_email.pl. Search for an existing version 
(like "3.3"), and update both places it occurs to handle the new 
version through copy and paste.

Doing diffs in wwwdocs/bugzilla/contrib:
*** ./bug_email.pl.~1~  Thu Aug 26 10:19:45 2004
--- ./bug_email.pl      Thu Sep  9 15:06:34 2004
*************** sub writeBugIntoDB
*** 302,309 ****
       my($version) = "";
       my($release) = $fields{"Release"};
       if ($release ne "") {
!           if ($release =~ /.*3\.5\.0.*/o) {
!           $version = "3.5.0";
       }
       elsif ($release =~ /.*3\.4\.3.*/o) {
             $version = "3.4.3";
--- 302,312 ----
       my($version) = "";
       my($release) = $fields{"Release"};
       if ($release ne "") {
!           if ($release =~ /.*4\.0\.0.*/o) {
!           $version = "4.0.0";
!     }
!     elsif ($release =~ /.*3\.5\.0.*/o) {
!           $version = "4.0.0";
       }
       elsif ($release =~ /.*3\.4\.3.*/o) {
             $version = "3.4.3";
--------------

Ok?

I ask because I wasn't sure if we should leave 3.5.0 in here, or remove 
it entirely.

Re: SC decision on version numbering: 4.0

[Joseph S. Myers]

On Thu, 9 Sep 2004, Mike Stump wrote:

> I ask because I wasn't sure if we should leave 3.5.0 in here, or remove it
> entirely.

We have 2.96 and 2.97 versions in the database, which track that bugs were 
reported against mainline in given date ranges, though there were no such 
releases.  But in the present instance the database seems to have been 
bulk converted from 3.5 to 4.0 without keeping such a distinction in the 
reported versions.

-- 
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: SC decision on version numbering: 4.0

[Daniel Berlin]

>
> Ok?
Yup.

>
> I ask because I wasn't sure if we should leave 3.5.0 in here, or remove it 
> entirely.
>

The version no longer exists in bugzilla, so doing that is a bad idea.

Re: SC decision on version numbering: 4.0

[Daniel Berlin]

On Thu, 9 Sep 2004, Joseph S. Myers wrote:

> On Thu, 9 Sep 2004, Mike Stump wrote:
>
>> I ask because I wasn't sure if we should leave 3.5.0 in here, or remove it
>> entirely.
>
> We have 2.96 and 2.97 versions in the database, which track that bugs were
> reported against mainline in given date ranges, though there were no such
> releases.  But in the present instance the database seems to have been
> bulk converted from 3.5 to 4.0 without keeping such a distinction in the
> reported versions.

Wasn't me, :)
I think andrew did it.

Snapshots? (was Re: SC decision on version numbering: 4.0)

[Phil Edwards]

On Thu, Sep 09, 2004 at 04:55:53PM -0700, Mike Stump wrote:
> Checked in as (now) obvious.  The other two are checked in as well, and 
> I don't understand that any more changes are necessary.  Let me know if 
> I got that wrong.

I /thknk/ you got them all.


> maintainer-scripts might need caressing...  I see:
> 
> 43 17 * * 7 sh /home/gccadmin/scripts/gcc_release -s 3.5:HEAD           
> -l -d /sourceware/snapshot-tmp/gcc all
> 
> in crontab, but am unsure if bumping this to 4.0.0 (or 4.0) is 
> correct/wise.

Yes but not yet, would be my vote.


> Also, that would require updating a crontab for 
> gccadmin, whcih I think I just want to punt to the _right_ person...

I can handle the gccadmin part, IIRC.

-- 
To begin the test, pull the power plug from the UPS.  The first time that
you do this, psychologically it won't be easy, but after you have pulled the
plug a few times, you may even come to enjoy it.           - apcupsd manual

Re: SC decision on version numbering: 4.0

[Giovanni Bajo]

Per Bothner wrote:

> The Steering Committee has decided that the the version number of
> the next mainline-based tree-ssa-based release should be "4.0".

This is mostly obvious, but previously SC decided that X.Y versions would have
to be called X.Y.0 for consistency. So, here we are speaking of "4.0.0", unless
something changed in that regard (but I wouldn't see why).

Giovanni Bajo

Re: SC decision on version numbering: 4.0

[Mark Mitchell]

Giovanni Bajo wrote:

>Per Bothner wrote:
>
>  
>
>>The Steering Committee has decided that the the version number of
>>the next mainline-based tree-ssa-based release should be "4.0".
>>    
>>
>
>This is mostly obvious, but previously SC decided that X.Y versions would have
>to be called X.Y.0 for consistency. So, here we are speaking of "4.0.0", unless
>something changed in that regard (but I wouldn't see why).
>  
>
Yes, I think 4.0.0 is what we mean.

-- 
Mark Mitchell
CodeSourcery, LLC
(916) 791-8304
mark@codesourcery.com

RE: SC decision on version numbering: 4.0

[Dave Korn]

> -----Original Message-----
> From: gcc-owner On Behalf Of Joseph S. Myers
> Sent: 10 September 2004 00:29
> To: Mike Stump
> Cc: Per Bothner; GCC Mailing List; gcc-patches
> Subject: Re: SC decision on version numbering: 4.0
> 
> On Thu, 9 Sep 2004, Mike Stump wrote:


[...ker-snip!...]

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

  Hey!  I just found another bit that needs patching!  8^D

    cheers, 
      DaveK
-- 
Can't think of a witty .sigline today....

Re: SC decision on version numbering: 4.0

[Mike Stump]

On Friday, September 10, 2004, at 05:07  AM, Dave Korn wrote:
>> 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
>                                                                        
> ^^^^^^^
>
>   Hey!  I just found another bit that needs patching!  8^D

Ok, thanks for noticing...  I broke into his machine (boy was that 
easy, it's an unpacthed Windows box) and updated his signature file.


:-)

Re: SC decision on version numbering: 4.0

[Gerald Pfeifer]

On Thu, 9 Sep 2004, Joseph S. Myers wrote:
> branching.html lists all the places that need changing for new major
> versions (mutatis mutandis for this case where the version number changes
> on mainline without an associated branch).  It is however out of date with
> regard to Gerald's changes to do snapshots from multiple branches; some
> special measures may be needed so that the first 4.0 snapshot has diffs
> from the last 3.5 one (and branching.html should document the applicable
> special measures).

Done thusly.

That won't win a beauty contest, but it works reasonably well.

Gerald

Index: branching.html
===================================================================
RCS file: /cvs/gcc/wwwdocs/htdocs/branching.html,v
retrieving revision 1.16
diff -u -3 -p -r1.16 branching.html
--- branching.html	27 Aug 2004 16:13:32 -0000	1.16
+++ branching.html	11 Sep 2004 19:53:17 -0000
@@ -45,14 +45,20 @@ release branch, the current release seri
  <li>Update <code>doc/include/gcc-common.texi</code> on the branch to use
  <code>@clear DEVELOPMENT</code>.</li>

-<li>Update <code>maintainer-scripts/gcc_release</code> on the
-mainline, where it says &quot;# For now snapshots come from the
-mainline.&quot;, to make snapshots come from the branch instead.
-Also update the description of where snapshots come from in
-<code>maintainer-scripts/snapshot-README</code>.
-(Also, <code>cvs update</code> will also need to be run in the scripts
-directory in the <code>gccadmin</code> account, to update the version
-actually called from cron.)</li>
+<li>Update <code>maintainer-scripts/crontab</code> on the mainline by
+adding an entry to make shapshots of the new branch and adjusting the
+version number of the mainline snapshots.
+Run <code>cvs update</code> in the <code>scripts</code> directory of
+the gccadmin account, and then actually install the updated crontab
+there.
+<br />
+Generate the next mainline snapshot manually, using the <code>-p</code>
+option of the <code>gcc_release</code> script.  For that single run,
+adjust the script such that the announcement mail is sent to you
+personally so that you can adjust references to the previous snapshot
+in the  <code>README</code> and <code>index.html</code> files of the
+new snapshot as well as the mail itself before relaying it.
+</li>

  <li><a href="translation.html#regen">Regenerate
  <code>gcc.pot</code></a> and <code>cpplib.pot</code>.