Re: PATCH: Bump version on mainline

[Mark Mitchell <mark at codesourcery dot com>]

Joseph S. Myers wrote:
> On Mon, 28 Feb 2005, Mark Mitchell wrote:
>
>
> > I don't see that having the sources that are actually tagged match the tarball
> > with respect to version.c is terribly important if they don't match
> > everywhere.  And, there may even be value in having them *not* match; it
> > reduces the chance that people will have versions of GCC that report
> > themselves as being the official release unless they built from the release
> > tarball.
>
>
> I think a build from the CVS tag for the release by someone with the right 
> tools should be just as official as one from the release tarball.

I agree, but the situation I was referring to was not this one, but 
rather the situation in which you have a checked out version which is 
not in fact the official release, but just happens not to have 
"prerelease" in version.c.  Such a version will inevitably exist if we 
have to check-ins as part of the release process, as we may have to run 
the release script multiple times if things go wrong.

I'm not claiming this problem is critical, but neither do I see the fact 
that "cvs export" doesn't exactly match the version.c in the tarball as 
incredibly critical.

Part of my beef here is that I think the release checklists have gotten 
to include a fair amount of makework that has limited value.  Right now 
we have a 19-step check-list.  Scripting more of that is good, but 
scripts have bugs and tend to break.  Eliminating the work would be 
better.

Concretely, I'd like to remove or simplify:

3. Check for new message translations.

Automate via a cronjob?

7. Update releases.html and develop.html web pages.

Could we auto-generate releases.html content on the web server by 
looking at directories on the FTP server?

9. Add the release tag to cvs.html.

This step is totally pointless; all reasonably recent release tags have 
the same format.  Just list the exceptions for old releases, and the 
format used for recent releases, and be done with it.

14. Increment the version number in gcc/version.c, and put back the date 
stamp and (prerelease) annotation. Increment the version number in 
doc/include/gcc-common.texi.

I don't like the idea of doing this increment automatically, because I 
don't think it's a good idea to bump the version number until we're 
happy with the release tarball, and ready to make it available. 
Otherwise, rerunning the release script might bump it twice, etc.

I think that this should require touching one file to update the version 
number, when the release has been uploaded to the FTP servers, but just one.

16-18. [Bugzilla manipulations] Should be entirely automated in a single 
script to be run on gcc.gnu.org.

19. Update the email parsing script to handle bugs against the new versions.

Can we find a way to generalize the script so that it doesn't need to be 
updated?  (For example, by asking bugzilla what versions it knows 
about?)  And do we need to continue to support submission of bugs by email?

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