This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: GCC Release Delay
- To: Mark Mitchell <mark at codesourcery dot com>
- Subject: Re: GCC Release Delay
- From: "Joseph S. Myers" <jsm28 at cam dot ac dot uk>
- Date: Mon, 18 Jun 2001 09:21:15 +0100 (BST)
- cc: "H . J . Lu" <hjl at lucon dot org>, "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
On Mon, 18 Jun 2001, Mark Mitchell wrote:
> This was semi-intentional. I have no idea how the libf2c version numbers
> track our releases. (The library could well be experimental, even if the
> compiler is not.) I didn't know that Fortran had its own version
> file; the fix is to remove it, and share the gcc/version.c file.
Fortran has its own version number (0.5.xx) which is presumably why it has
its own version.c file. Whether, now it is part of GCC, it needs its own
version number, is another matter.
> Would you mind submitting patches for gcc_release to do whatever you
> think is right, both for the version files and to fix the ChangeLog
> date issue? Then we won't have the same problem in the next release.
What do we want to do with the dates and (release) in version files? For
GCC, a simple "3.0" (as in the release) is unambiguous, but for the
Fortran files the subminor version number is updated only for GCC minor
releases, not with each patchlevel.
Before any other changes are made on the branch, all the version files
should change to saying (prerelease) (and 3.0.1, for gcc/version.c) to
avoid confusion about what version bug reports are being made against.
--
Joseph S. Myers
jsm28@cam.ac.uk