From: Andreas Ericsson Date: Sat, 30 Aug 2008 08:13:46 GMT Subject: Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins Message-ID: <48B9013A.70201@op5.se> In-Reply-To: <94a0d4530808290928w3b1decd4o2e77349d793ffff0@mail.gmail.com> Felipe Contreras wrote: > On Fri, Aug 29, 2008 at 7:24 PM, Aidan Van Dyk wrote: >> * Felipe Contreras [080829 12:11]: >>> On Fri, Aug 29, 2008 at 6:24 PM, Aidan Van Dyk wrote: >>>> * Perry Wagle [080801 00:00]: >>>>> Jeff King has convinced me that it's perfectly legitimate to introduce >>>>> non-upward compatibilities in minor version releases of "young" >>>>> software. >>>> This is the gist of the problem. You keep hammering about a >>>> "non-upwards compatibilities in minor version releases", yet you have >>>> *not* pointed out one such in-compatibility in a minor version release.. >>>> >>>> Remember, in git, 1.6 is a "major version" release, with release notes, etc. >>>> 1.5.X is a "minor version" release. >>>> 1.5.X.Y is a "patch" release. >>> What is X (2.0)? >> X would be a digit, like 0, 1, 2, 3, 4, 5, 6, 7, 8, or 9, as in the git >> 1.5 releases: >> 1.5.0 >> 1.5.1 >> 1.5.2 >> 1.5.3 >> 1.5.4 >> 1.5.4 >> 1.5.6 >> >> And now also: >> 1.6.0, being the first of the 1.6 releases... > > I meant 'X.0.0', if 1.X is major, what is X.0? Huge? > X.0 is "technically backwards incompatible". If, for example, SHA1 turns out to be horribly broken, git might have to be updated to use something else instead. Such a switch would require a version bump from 1.x to 2.x. That might come some day anyway, assuming we decide to make a flag-day and just remove older-version compatibility code from git or some such. -- Andreas Ericsson andreas.ericsson@op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231