This is the mail archive of the gcc-patches@gcc.gnu.org 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:

The files which get changed for a release could, within the script itself, be automatically changed, checked in, the release tagged and made and then the files changed back by the script. The only bit it doesn't do of that is:

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.


but the script could clearly be made to do so, and so to keep the files tagged in CVS corresponding to those in the release. The script already updates and checks in version.c to remove the date and (prerelease tag), it just doesn't put them back (with increased version number) afterwards.

Yes -- but this bit has always seemed fragile to me. We've had problems when the release script has for some reason failed; then, we can get multiple updates. We could also end up in the situation where we've got multiple revisions of version.c without the "prerelease" marker, meaning that checking out a version that was not actually the same as the release would report its version as if it were in fact the release.


In general, I'd rather the release script apply the tag, but not atually do any check-in operations. If making the release source tarball were as simple as "cvs export", then it might be worth doing the check-ins, but it's not presently that simple, and it doesn't look like it's likely to be that simple any time soon. (There seems to be consensus that we should not require users to have the tools required to generate some of the generated files.)

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.

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


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