This is the mail archive of the
mailing list for the GCC project.
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
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.