On Sunday 20 May 2001 6:11 am, Tom Tromey wrote:
> >>>>> "Gary" == Gary V Vaughan <[EMAIL PROTECTED]> writes:
>
> Gary> But it does raise the general problem of how to differentiate
> Gary> between alpha releases and full releases when using a fork
> Gary> identifier.
>
> I think `1.5a-myversion' is an alpha version according to the rules.
Agreed. Buuut... 1.4a-p1 seems wrong if HEAD is at 1.4c. Worse, releasing
1.4b-p1 sounds like it is related to 1.4b. I still don't like it, and won't
adopt it for libtool or m4.
> As I recall, a long time ago the Gnits group decided that we simply
> wouldn't support more than 2 release numbers. If the current release
> is 1.4, then the next one is 1.5. Unfortunately for us, I didn't want
> to do this with automake since I've been saying for a long time "1.5
> will do this", "1.5 will do that". Bleah, my bad.
I am aware of *very* few projects that can stick to this rule in practice.
It is easy to contrive examples which cause this system to breakdown.
> The fork identifier stuff is just so that people who make their own
> version of automake, which happens depressingly often, can somehow
> mark it without intefering with a Makefile.am where a version number
> is in AUTOMAKE_OPTIONS.
I'm okay with that, as long as we acknowledge that they really don't work
in CVS.
> In all this is an ugly situation. I'm thinking of hacking automake to
> recognize that `1.4-p<N>' is between 1.4 and 1.5 (so that
> AUTOMAKE_OPTIONS=1.4-p1 will work ok when 1.5 is used).
>
> In the future I'll be more careful about how I talk about the next
> release, and about release processes in general. For instance the
> release after 1.5 -- whether it is a major feature release or a simple
> bug fix release -- will be named 1.6.
So CVS will become 1.5a, and maybe you'll release 1.5b and change CVS to
1.5c, and in the mean while you need a patch for the original 1.5, so you
call that 1.6 (even though it is ``worse'' than 1.5a) and make change CVS
HEAD to what? 1.6a? And what number will the CVS branch that 1.6 came from
have?
I still think that a three point release number is infinitely cleaner in
situations like this.
Alternatively, maybe you could increment the major number for releases along
mainline, and the minor number for patch releases?
Cheers,
Gary.
--
())_. Gary V. Vaughan gary@(oranda.demon.co.uk|gnu.org)
( '/ Research Scientist http://www.oranda.demon.co.uk ,_())____
/ )= GNU Hacker http://www.gnu.org/software/libtool \' `&
`(_~)_ Tech' Author http://sources.redhat.com/autobook =`---d__/
