[ANNOUNCE] GIT 1.0.0b quickfix

[ANNOUNCE] GIT 1.0.0b quickfix

[Junio C Hamano]

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

Re: [ANNOUNCE] GIT 1.0.0b quickfix

[H. Peter Anvin]

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

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

	-hpa

Re: [ANNOUNCE] GIT 1.0.0b quickfix

[Junio C Hamano]

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

> Junio C Hamano wrote:
>> I've pushed out a v1.0.0b maint release to fix a bug in HTTP
>> fetch that was discovered today X-<.
>>
>
> Wouldn't it make more sense for the maintenance release to be 1.0.1?

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.

Re: [ANNOUNCE] GIT 1.0.0b quickfix

[H. Peter Anvin]

Junio C Hamano wrote:
> "H. Peter Anvin" <hpa@zytor.com> writes:
> 
> 
>>Junio C Hamano wrote:
>>
>>>I've pushed out a v1.0.0b maint release to fix a bug in HTTP
>>>fetch that was discovered today X-<.
>>>
>>
>>Wouldn't it make more sense for the maintenance release to be 1.0.1?
> 
> 
> Maybe.  Nobody mentioned this about 0.99.9a, 0.99.9b... though.

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

> 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.

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

	-hpa

Re: [ANNOUNCE] GIT 1.0.0b quickfix

[Junio C Hamano]

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

>>>Wouldn't it make more sense for the maintenance release to be 1.0.1?
>> Maybe.  Nobody mentioned this about 0.99.9a, 0.99.9b... though.
>
> Yeah, well, the 0.99 bit in front kind of had made that hard to do.

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

>> 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.
>
> Well, the Linux numbering scheme has gotten ridiculous, with the 2. in 
> front having no meaning.

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?

Re: [ANNOUNCE] GIT 1.0.0b quickfix

[H. Peter Anvin]

Junio C Hamano wrote:
> 
> 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?
> 

I think that would make sense.

	-hpa

Re: [ANNOUNCE] GIT 1.0.0b quickfix

[Benjamin Herrenschmidt]

On Wed, 2005-12-21 at 15:12 -0800, H. Peter Anvin wrote:
> Junio C Hamano wrote:
> > I've pushed out a v1.0.0b maint release to fix a bug in HTTP
> > fetch that was discovered today X-<.
> > 
> 
> Wouldn't it make more sense for the maintenance release to be 1.0.1?

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

Ben.

Re: [ANNOUNCE] GIT 1.0.0b quickfix

[Linus Torvalds]

On Thu, 22 Dec 2005, Benjamin Herrenschmidt wrote:
> > 
> > Wouldn't it make more sense for the maintenance release to be 1.0.1?
> 
> Seconded. letters in versions are bad. With my MacOS background, for me,
> "b" means "beta" :)

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

Re: [ANNOUNCE] GIT 1.0.0b quickfix

[Junio C Hamano]

Linus Torvalds <torvalds@osdl.org> writes:

> On Thu, 22 Dec 2005, Benjamin Herrenschmidt wrote:
>> > 
>> > Wouldn't it make more sense for the maintenance release to be 1.0.1?
>> 
>> Seconded. letters in versions are bad. With my MacOS background, for me,
>> "b" means "beta" :)
>
> 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.

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>

Re: [ANNOUNCE] GIT 1.0.0b quickfix

[Ingo Oeser]

On Thursday 22 December 2005 18:46, Linus Torvalds wrote:
> On Thu, 22 Dec 2005, Benjamin Herrenschmidt wrote:
> > > Wouldn't it make more sense for the maintenance release to be 1.0.1?
> > Seconded. letters in versions are bad. With my MacOS background, for me,
> > "b" means "beta" :)
> 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.

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

Re: [ANNOUNCE] GIT 1.0.0b quickfix

[Junio C Hamano]

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

> Also sucks because letters after numbers a read as "units".
>
> Just compare 5h, 3kg, 20cm, 9in, 1.3h

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?

Re: [ANNOUNCE] GIT 1.0.0b quickfix

[Andreas Ericsson]

Junio C Hamano wrote:
> 
> *1* Which one is the heaviest, 5h, 3kg, or 20cm?
> 

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                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Re: [ANNOUNCE] GIT 1.0.0b quickfix

[Krzysztof Halasa]

Andreas Ericsson <ae@op5.se> writes:

>> *1* Which one is the heaviest, 5h, 3kg, or 20cm?
>>
>
> 5h, without a doubt. Because time can be broken down into infinitely
> small pieces

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

Re: [ANNOUNCE] GIT 1.0.0b quickfix

[H. Peter Anvin]

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

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