All of lore.kernel.org
 help / color / mirror / Atom feed
* [ANNOUNCE] GIT 0.99.7b
@ 2005-09-23  6:18 Junio C Hamano
  2005-09-23 13:11 ` walt
  0 siblings, 1 reply; 9+ messages in thread
From: Junio C Hamano @ 2005-09-23  6:18 UTC (permalink / raw)
  To: git

GIT 0.99.7b

Contains the following post-0.99.7a fixes:

 - Commit walker performance fix, mostly during walking commits
   in a downloaded packfile, thanks to Sergey Vlasov.

 - Squelch unnecessarily alarming error message from fetch and
   clone over rsync transport, when remote repository does not
   borrow anything from other repositories.

   I've seen enough people got annoyed/worried/alarmed after
   seeing this one on both git and linux-kernel list.

 - Documentation was not rebuilt before installation, noticed by
   Randal L Schwartz.

 - Fetching of objects over http transport got a bit safer.


Tarballs, RPMs and Debs are available at

	http://kernel.org/pub/software/scm/git/

Or, if you use git already:

	{http,rsync}://kernel.org/pub/scm/git/git.git/

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [ANNOUNCE] GIT 0.99.7b
  2005-09-23  6:18 [ANNOUNCE] GIT 0.99.7b Junio C Hamano
@ 2005-09-23 13:11 ` walt
  2005-09-23 19:44   ` H. Peter Anvin
  2005-09-23 20:46   ` Junio C Hamano
  0 siblings, 2 replies; 9+ messages in thread
From: walt @ 2005-09-23 13:11 UTC (permalink / raw)
  To: git

Junio C Hamano wrote:
> GIT 0.99.7b
[...]
> Or, if you use git already:
> 
> 	{http,rsync}://kernel.org/pub/scm/git/git.git/

I did it that way and now I see this:

$git --version
git version 0.99.7

This is a bit confusing.  Did I upgrade or downgrade?
Maybe the version string should contain the same kind
of hexadecimal string that Linus is appending to his
kernel version?

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [ANNOUNCE] GIT 0.99.7b
  2005-09-23 13:11 ` walt
@ 2005-09-23 19:44   ` H. Peter Anvin
  2005-09-23 20:46   ` Junio C Hamano
  1 sibling, 0 replies; 9+ messages in thread
From: H. Peter Anvin @ 2005-09-23 19:44 UTC (permalink / raw)
  To: walt; +Cc: git

walt wrote:
> Junio C Hamano wrote:
> 
>> GIT 0.99.7b
> 
> [...]
> 
>> Or, if you use git already:
>>
>>     {http,rsync}://kernel.org/pub/scm/git/git.git/
> 
> 
> I did it that way and now I see this:
> 
> $git --version
> git version 0.99.7
> 
> This is a bit confusing.  Did I upgrade or downgrade?
> Maybe the version string should contain the same kind
> of hexadecimal string that Linus is appending to his
> kernel version?
> 

Or just call it 0.99.7.1 and .2 or 0.99.8 and .9.

	-hpa

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [ANNOUNCE] GIT 0.99.7b
  2005-09-23 13:11 ` walt
  2005-09-23 19:44   ` H. Peter Anvin
@ 2005-09-23 20:46   ` Junio C Hamano
  2005-09-23 20:52     ` Joel Becker
  2005-09-23 20:54     ` Petr Baudis
  1 sibling, 2 replies; 9+ messages in thread
From: Junio C Hamano @ 2005-09-23 20:46 UTC (permalink / raw)
  To: walt; +Cc: git

walt <wa1ter@myrealbox.com> writes:

> Junio C Hamano wrote:
>> GIT 0.99.7b
> [...]
>> Or, if you use git already:
>> 	{http,rsync}://kernel.org/pub/scm/git/git.git/
>
> I did it that way and now I see this:

If you fetched v0.99.7b tag and built it, hopefully it should
say 0.99.7b otherwise you found a big bug.

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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [ANNOUNCE] GIT 0.99.7b
  2005-09-23 20:46   ` Junio C Hamano
@ 2005-09-23 20:52     ` Joel Becker
  2005-09-23 20:55       ` Petr Baudis
  2005-09-23 21:45       ` Junio C Hamano
  2005-09-23 20:54     ` Petr Baudis
  1 sibling, 2 replies; 9+ messages in thread
From: Joel Becker @ 2005-09-23 20:52 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: walt, git

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.

Joel

-- 

Life's Little Instruction Book #451

	"Don't be afraid to say, 'I'm sorry.'"

Joel Becker
Principal Software Developer
Oracle
E-mail: joel.becker@oracle.com
Phone: (650) 506-8127

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [ANNOUNCE] GIT 0.99.7b
  2005-09-23 20:46   ` Junio C Hamano
  2005-09-23 20:52     ` Joel Becker
@ 2005-09-23 20:54     ` Petr Baudis
  2005-09-24 21:59       ` Junio C Hamano
  1 sibling, 1 reply; 9+ messages in thread
From: Petr Baudis @ 2005-09-23 20:54 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: walt, git

Dear diary, on Fri, Sep 23, 2005 at 10:46:14PM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> told me that...
> 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...

In ELinks, we pseudo-bump the version number from v1.2.3 to v1.2.3.CVS
(now v1.2.3.GIT) right after the release.

In Cogito, we append the commit ID current at the time of build to
cg-version output (if it was built from GIT-tracked working directory).

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [ANNOUNCE] GIT 0.99.7b
  2005-09-23 20:52     ` Joel Becker
@ 2005-09-23 20:55       ` Petr Baudis
  2005-09-23 21:45       ` Junio C Hamano
  1 sibling, 0 replies; 9+ messages in thread
From: Petr Baudis @ 2005-09-23 20:55 UTC (permalink / raw)
  To: Joel Becker; +Cc: Junio C Hamano, walt, git

Dear diary, on Fri, Sep 23, 2005 at 10:52:42PM CEST, I got a letter
where Joel Becker <Joel.Becker@oracle.com> told me that...
> 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.

The point is that the bugfix releases aren't tagged on the master branch
but on the maint branch.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [ANNOUNCE] GIT 0.99.7b
  2005-09-23 20:52     ` Joel Becker
  2005-09-23 20:55       ` Petr Baudis
@ 2005-09-23 21:45       ` Junio C Hamano
  1 sibling, 0 replies; 9+ messages in thread
From: Junio C Hamano @ 2005-09-23 21:45 UTC (permalink / raw)
  To: Joel Becker; +Cc: walt, git

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

> 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'?

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [ANNOUNCE] GIT 0.99.7b
  2005-09-23 20:54     ` Petr Baudis
@ 2005-09-24 21:59       ` Junio C Hamano
  0 siblings, 0 replies; 9+ messages in thread
From: Junio C Hamano @ 2005-09-24 21:59 UTC (permalink / raw)
  To: Petr Baudis; +Cc: git

Petr Baudis <pasky@suse.cz> writes:

> Dear diary, on Fri, Sep 23, 2005 at 10:46:14PM CEST, I got a letter
> where Junio C Hamano <junkio@cox.net> told me that...
>> 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...
>
> In ELinks, we pseudo-bump the version number from v1.2.3 to v1.2.3.CVS
> (now v1.2.3.GIT) right after the release.

That's a nice way of doing it.  Maybe I should follow suit.

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2005-09-24 21:59 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2005-09-23  6:18 [ANNOUNCE] GIT 0.99.7b Junio C Hamano
2005-09-23 13:11 ` walt
2005-09-23 19:44   ` H. Peter Anvin
2005-09-23 20:46   ` Junio C Hamano
2005-09-23 20:52     ` Joel Becker
2005-09-23 20:55       ` Petr Baudis
2005-09-23 21:45       ` Junio C Hamano
2005-09-23 20:54     ` Petr Baudis
2005-09-24 21:59       ` Junio C Hamano

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.