Re: [ANNOUNCE] GIT 0.99.7b

From: Junio C Hamano <junkio@cox.net>
Date: Sep 23, 2005, 21:45 UTC
Message-ID: <7v4q8ba260.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <20050923205242.GY27375@ca-server1.us.oracle.com>

Joel Becker <Joel.Becker@oracle.com> writes:

Show 9 quoted lines

> On Fri, Sep 23, 2005 at 01:46:14PM -0700, Junio C Hamano wrote:
>> If you pulled from "master" branch, then --version would still
>> say 0.99.7; I agree it is confusing.  On the other hand, I do
>> not think we would want to increment the version string with
>> every little changes, so...
>
> 	Every little change, no.  But ANNOUNCEd releases should be
> considered 'major' from this point of view.  I don't think a little
> extra version number incrementing is too big a deal.

Yes, 'maint' has the GIT_VERSION bumped in the Makefile (0.99.7a, 0.99.7b) and that is propagated to 'git --version'.

What I was having trouble was what to do with the stuff we put in the 'master' between 0.99.7 and 0.99.8. 'maint' was *forked* from 0.99.7, not just tagging some midpoint in 'master' line for obvious reasons, so the 'git --version' on the 'master' side does not have much to do with what happens on the 'maint' side.

We could say, immediately after 0.99.7 is released, bump the GIT_VERSION in the 'master' branch to 0.99.8-pre or something like that.

We need to pick something that sorts after '0.99.7a', '0.99.7b', etc. and before '0.99.8'. Somebody needs to come up with what is appropriate for version number ordering scheme employed by binary packaged distributions. I know 0.99.8-pre does not sort before 0.99.8 on Debian. Probably '0.99.7zzz'?