This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: PATCH: Bump version on mainline

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

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

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
(916) 791-8304

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]