{"thread":{"id":"1919","subject":"[ANNOUNCE] GIT 0.99.7b","startedAt":"2005-09-23T06:18:44Z","lastAt":"2005-09-24T21:59:05Z","messageCount":9,"participants":["Junio C Hamano","walt","H. Peter Anvin","Joel Becker","Petr Baudis"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"9152","messageId":"7voe6ki9x7.fsf@assigned-by-dhcp.cox.net","threadId":"1919","inReplyTo":null,"subject":"[ANNOUNCE] GIT 0.99.7b","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-09-23T06:18:44Z","receivedAt":"2005-09-23T06:18:44Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"GIT 0.99.7b\n\nContains the following post-0.99.7a fixes:\n\n - Commit walker performance fix, mostly during walking commits\n   in a downloaded packfile, thanks to Sergey Vlasov.\n\n - Squelch unnecessarily alarming error message from fetch and\n   clone over rsync transport, when remote repository does not\n   borrow anything from other repositories.\n\n   I've seen enough people got annoyed/worried/alarmed after\n   seeing this one on both git and linux-kernel list.\n\n - Documentation was not rebuilt before installation, noticed by\n   Randal L Schwartz.\n\n - Fetching of objects over http transport got a bit safer.\n\n\nTarballs, RPMs and Debs are available at\n\n\thttp://kernel.org/pub/software/scm/git/\n\nOr, if you use git already:\n\n\t{http,rsync}://kernel.org/pub/scm/git/git.git/\n"},{"id":"9183","messageId":"dh0uur$h4g$1@sea.gmane.org","threadId":"1919","inReplyTo":"7voe6ki9x7.fsf@assigned-by-dhcp.cox.net","subject":"Re: [ANNOUNCE] GIT 0.99.7b","fromName":"walt","fromEmail":"wa1ter@myrealbox.com","sentAt":"2005-09-23T13:11:54Z","receivedAt":"2005-09-23T13:11:54Z","isPatch":false,"sender":{"key":"wa1ter@myrealbox.com","avatar":null},"body":"Junio C Hamano wrote:\n> GIT 0.99.7b\n[...]\n> Or, if you use git already:\n> \n> \t{http,rsync}://kernel.org/pub/scm/git/git.git/\n\nI did it that way and now I see this:\n\n$git --version\ngit version 0.99.7\n\nThis is a bit confusing.  Did I upgrade or downgrade?\nMaybe the version string should contain the same kind\nof hexadecimal string that Linus is appending to his\nkernel version?\n"},{"id":"9189","messageId":"43345B11.4000009@zytor.com","threadId":"1919","inReplyTo":"dh0uur$h4g$1@sea.gmane.org","subject":"Re: [ANNOUNCE] GIT 0.99.7b","fromName":"H. Peter Anvin","fromEmail":"hpa@zytor.com","sentAt":"2005-09-23T19:44:17Z","receivedAt":"2005-09-23T19:44:17Z","isPatch":false,"sender":{"key":"hpa@zytor.com","avatar":null},"body":"walt wrote:\n> Junio C Hamano wrote:\n> \n>> GIT 0.99.7b\n> \n> [...]\n> \n>> Or, if you use git already:\n>>\n>>     {http,rsync}://kernel.org/pub/scm/git/git.git/\n> \n> \n> I did it that way and now I see this:\n> \n> $git --version\n> git version 0.99.7\n> \n> This is a bit confusing.  Did I upgrade or downgrade?\n> Maybe the version string should contain the same kind\n> of hexadecimal string that Linus is appending to his\n> kernel version?\n> \n\nOr just call it 0.99.7.1 and .2 or 0.99.8 and .9.\n\n\t-hpa\n"},{"id":"9194","messageId":"7v8xxnbjhl.fsf@assigned-by-dhcp.cox.net","threadId":"1919","inReplyTo":"dh0uur$h4g$1@sea.gmane.org","subject":"Re: [ANNOUNCE] GIT 0.99.7b","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-09-23T20:46:14Z","receivedAt":"2005-09-23T20:46:14Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"walt <wa1ter@myrealbox.com> writes:\n\n> Junio C Hamano wrote:\n>> GIT 0.99.7b\n> [...]\n>> Or, if you use git already:\n>> \t{http,rsync}://kernel.org/pub/scm/git/git.git/\n>\n> I did it that way and now I see this:\n\nIf you fetched v0.99.7b tag and built it, hopefully it should\nsay 0.99.7b otherwise you found a big bug.\n\nIf you pulled from \"master\" branch, then --version would still\nsay 0.99.7; I agree it is confusing.  On the other hand, I do\nnot think we would want to increment the version string with\nevery little changes, so...\n"},{"id":"9195","messageId":"20050923205242.GY27375@ca-server1.us.oracle.com","threadId":"1919","inReplyTo":"7v8xxnbjhl.fsf@assigned-by-dhcp.cox.net","subject":"Re: [ANNOUNCE] GIT 0.99.7b","fromName":"Joel Becker","fromEmail":"joel.becker@oracle.com","sentAt":"2005-09-23T20:52:42Z","receivedAt":"2005-09-23T20:52:42Z","isPatch":false,"sender":{"key":"joel.becker@oracle.com","avatar":null},"body":"On Fri, Sep 23, 2005 at 01:46:14PM -0700, Junio C Hamano wrote:\n> If you pulled from \"master\" branch, then --version would still\n> say 0.99.7; I agree it is confusing.  On the other hand, I do\n> not think we would want to increment the version string with\n> every little changes, so...\n\n\tEvery little change, no.  But ANNOUNCEd releases should be\nconsidered 'major' from this point of view.  I don't think a little\nextra version number incrementing is too big a deal.\n\nJoel\n\n-- \n\nLife's Little Instruction Book #451\n\n\t\"Don't be afraid to say, 'I'm sorry.'\"\n\nJoel Becker\nPrincipal Software Developer\nOracle\nE-mail: joel.becker@oracle.com\nPhone: (650) 506-8127\n"},{"id":"9196","messageId":"20050923205436.GF10255@pasky.or.cz","threadId":"1919","inReplyTo":"7v8xxnbjhl.fsf@assigned-by-dhcp.cox.net","subject":"Re: [ANNOUNCE] GIT 0.99.7b","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2005-09-23T20:54:36Z","receivedAt":"2005-09-23T20:54:36Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Fri, Sep 23, 2005 at 10:46:14PM CEST, I got a letter\nwhere Junio C Hamano <junkio@cox.net> told me that...\n> If you pulled from \"master\" branch, then --version would still\n> say 0.99.7; I agree it is confusing.  On the other hand, I do\n> not think we would want to increment the version string with\n> every little changes, so...\n\nIn ELinks, we pseudo-bump the version number from v1.2.3 to v1.2.3.CVS\n(now v1.2.3.GIT) right after the release.\n\nIn Cogito, we append the commit ID current at the time of build to\ncg-version output (if it was built from GIT-tracked working directory).\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nVI has two modes: the one in which it beeps and the one in which\nit doesn't.\n"},{"id":"9197","messageId":"20050923205558.GG10255@pasky.or.cz","threadId":"1919","inReplyTo":"20050923205242.GY27375@ca-server1.us.oracle.com","subject":"Re: [ANNOUNCE] GIT 0.99.7b","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2005-09-23T20:55:58Z","receivedAt":"2005-09-23T20:55:58Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Fri, Sep 23, 2005 at 10:52:42PM CEST, I got a letter\nwhere Joel Becker <Joel.Becker@oracle.com> told me that...\n> On Fri, Sep 23, 2005 at 01:46:14PM -0700, Junio C Hamano wrote:\n> > If you pulled from \"master\" branch, then --version would still\n> > say 0.99.7; I agree it is confusing.  On the other hand, I do\n> > not think we would want to increment the version string with\n> > every little changes, so...\n> \n> \tEvery little change, no.  But ANNOUNCEd releases should be\n> considered 'major' from this point of view.  I don't think a little\n> extra version number incrementing is too big a deal.\n\nThe point is that the bugfix releases aren't tagged on the master branch\nbut on the maint branch.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nVI has two modes: the one in which it beeps and the one in which\nit doesn't.\n"},{"id":"9199","messageId":"7v4q8ba260.fsf@assigned-by-dhcp.cox.net","threadId":"1919","inReplyTo":"20050923205242.GY27375@ca-server1.us.oracle.com","subject":"Re: [ANNOUNCE] GIT 0.99.7b","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-09-23T21:45:43Z","receivedAt":"2005-09-23T21:45:43Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Joel Becker <Joel.Becker@oracle.com> writes:\n\n> On Fri, Sep 23, 2005 at 01:46:14PM -0700, Junio C Hamano wrote:\n>> If you pulled from \"master\" branch, then --version would still\n>> say 0.99.7; I agree it is confusing.  On the other hand, I do\n>> not think we would want to increment the version string with\n>> every little changes, so...\n>\n> \tEvery little change, no.  But ANNOUNCEd releases should be\n> considered 'major' from this point of view.  I don't think a little\n> extra version number incrementing is too big a deal.\n\nYes, 'maint' has the GIT_VERSION bumped in the Makefile\n(0.99.7a, 0.99.7b) and that is propagated to 'git --version'.\n\nWhat I was having trouble was what to do with the stuff we put\nin the 'master' between 0.99.7 and 0.99.8.  'maint' was *forked*\nfrom 0.99.7, not just tagging some midpoint in 'master' line for\nobvious reasons, so the 'git --version' on the 'master' side\ndoes not have much to do with what happens on the 'maint' side.\n\nWe could say, immediately after 0.99.7 is released, bump the\nGIT_VERSION in the 'master' branch to 0.99.8-pre or something\nlike that.\n\nWe need to pick something that sorts after '0.99.7a', '0.99.7b',\netc. and before '0.99.8'.  Somebody needs to come up with what\nis appropriate for version number ordering scheme employed by\nbinary packaged distributions.  I know 0.99.8-pre does not sort\nbefore 0.99.8 on Debian.  Probably '0.99.7zzz'?\n"},{"id":"9244","messageId":"7v64squnyu.fsf@assigned-by-dhcp.cox.net","threadId":"1919","inReplyTo":"20050923205436.GF10255@pasky.or.cz","subject":"Re: [ANNOUNCE] GIT 0.99.7b","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-09-24T21:59:05Z","receivedAt":"2005-09-24T21:59:05Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Petr Baudis <pasky@suse.cz> writes:\n\n> Dear diary, on Fri, Sep 23, 2005 at 10:46:14PM CEST, I got a letter\n> where Junio C Hamano <junkio@cox.net> told me that...\n>> If you pulled from \"master\" branch, then --version would still\n>> say 0.99.7; I agree it is confusing.  On the other hand, I do\n>> not think we would want to increment the version string with\n>> every little changes, so...\n>\n> In ELinks, we pseudo-bump the version number from v1.2.3 to v1.2.3.CVS\n> (now v1.2.3.GIT) right after the release.\n\nThat's a nice way of doing it.  Maybe I should follow suit.\n"}]}