[ANNOUNCE] GIT 1.0.0b quickfix

I've pushed out a v1.0.0b maint release to fix a bug in HTTP fetch that was discovered today X-<.

Junio C Hamano wrote:

Wouldn't it make more sense for the maintenance release to be 1.0.1?

	-hpa

"H. Peter Anvin" <hpa@zytor.com> writes:

Maybe.  Nobody mentioned this about 0.99.9a, 0.99.9b... though.

The series 1.0.0[a-z] is meant to parallel 2.6.14.[123...] "fixes only"; OTOH I'd like to allow 1.0.[123...] to contain enhancements.

Junio C Hamano wrote:

Yeah, well, the 0.99 bit in front kind of had made that hard to do.

Well, the Linux numbering scheme has gotten ridiculous, with the 2. in front having no meaning.

	-hpa

"H. Peter Anvin" <hpa@zytor.com> writes:

Well, I could have done 0.99.9.1 instead of 0.99.9a.

True.

We could do 1.0.0 (base 1.0 release), 1.0.1 (instead of 1.0.0a), 1.0.2 (instead of 1.0.0b) on the "maint" branch and 1.1.0 to be next minor feature release. Do you like it better?

Junio C Hamano wrote:

I think that would make sense.

	-hpa

On Wed, 2005-12-21 at 15:12 -0800, H. Peter Anvin wrote:

Seconded. letters in versions are bad. With my MacOS background, for me, "b" means "beta" :)

Ben.

On Thu, 22 Dec 2005, Benjamin Herrenschmidt wrote:

FWIW, thirded. The kernel used to use letters too, and it's cute, but just using multiple levels of release numbers is much more common.

		Linus

Linus Torvalds <torvalds@osdl.org> writes:

FWIW, fourthed ;-)

commit c894168631e4b7da66ed3993a4c92380d38599a8
Author: Junio C Hamano <junkio@cox.net>
Date:   Wed Dec 21 22:33:37 2005 -0800

    Versioning scheme changes.
    
    HPA suggests it is simply silly to imitate Linux versioning
    scheme where the leading "2" does not mean anything anymore, and
    I tend to agree.
    
    The first feature release after 1.0.0 will be 1.1.0, and the
    development path leading to 1.1.0 will carry 1.0.GIT as the
    version number from now on.  Similarly, the third maintenance
    release that follows 1.0.0 will not be 1.0.0c as planned, but
    will be called 1.0.3.  The "maint" branch will merge in fixes
    and immediately tagged, so there is no need for 1.0.2.GIT that
    is in between 1.0.2 (aka 1.0.0b) and 1.0.3.
    
    Signed-off-by: Junio C Hamano <junkio@cox.net>

On Thursday 22 December 2005 18:46, Linus Torvalds wrote:

Also sucks because letters after numbers a read as "units".

Just compare 5h, 3kg, 20cm, 9in, 1.3h

Also putting letters after version numbers usally gives me a feeling that the author is not sure about what he does. But this is just me, I guess

I hope util-linux is going to learn all that one day :-)

Regards

Ingo Oeser

Ingo Oeser <ioe-lkml@rameria.de> writes:

If your first reaction after seeing 0.99.7a 0.99.7b 0.99.7c was that they were numbers in unrelated units a b c and cannot be compared with each other, you need to get your head examined ;-).

I concede that it is a cute point you tried to make [*1*], but I do not think your presentation was convincing enough.

[Footnote]

*1* Which one is the heaviest, 5h, 3kg, or 20cm?

Junio C Hamano wrote:

5h, without a doubt. Because time can be broken down into infinitely small pieces and encompasses all the matter in the universe it will always be heavier and larger than any measurement relating to 3 dimensions or less.

Beware of rhetorical questions around people with hangovers in a philosohopical mood. ;)

Andreas Ericsson <ae@op5.se> writes:

This is uncertain. If the time is quantified 5 hrs might as well contain much less quanta than 3 kg, let alone 20 cm :-)

Krzysztof Halasa wrote:

You're forgetting that if time is quantized, it's as part of a general quantization of space-time. Thus, there would be as many quanta in 5 hrs as in 539,626,442,400,000 cm.

	-hpa