Re: Patch: One version number to rule them all

[Mark Mitchell <mark at codesourcery dot com>]

Joseph S. Myers wrote:
> On Wed, 2 Mar 2005, Zack Weinberg wrote:
>
>
> > and gcov-iov.c) or has had its need for a hardcoded version number
> > eliminated (gccbug, formerly gccbug.in).  I also attempted to update
> > the update_version and update_web_docs maintainer scripts.
>
>
> gccbug.in has more substitutions than just the version number 
> (@have_mktemp_command@, @host@, @build@, @target@, 
> @gcc_config_arguments@).
>
>
> > - Advice as to how to make gcc_release work with this new scheme
> >   without breaking for older release branches.
>
>
> I don't think gcc_release cares when generating snapshots.  For now old 
> release branches use the gcc_release version on those branches, but since 
> there are likely to be such release branches still live through a move to 
> Subversion it would be necessary either for several gcc_release script 
> versions to be adapted for Subversion or for the mainline version to 
> handle older release branches and be copied to them.  For that reason, I 
> think making gcc_release check whether version.c exists and update 
> different files depending on whether it does is worthwhile.

On the contrary, I think that having separate release scripts for the 
separate release branches is very sensible.  I'd hate to be unable to 
make major changes to the release script because of fear of breaking old 
releases.  I would say that it's just fine to make this change on the 
mainline release branch.  If/when we switch to Subversion, we can figure 
out how to deal with the issue.  There are only a handful of branches 
that are both active and old; applying the Subversion patch in a few 
places is not that big a deal.

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