Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins
- From
Andreas Ericsson <ae@op5.se>
- Date
- Aug 30, 2008, 08:13 UTC
- Message-ID
- <48B9013A.70201@op5.se>
- In-Reply-To
- <94a0d4530808290928w3b1decd4o2e77349d793ffff0@mail.gmail.com>
Felipe Contreras wrote:
Show 30 quoted lines
> On Fri, Aug 29, 2008 at 7:24 PM, Aidan Van Dyk <aidan@highrise.ca> wrote: >> * Felipe Contreras <felipe.contreras@gmail.com> [080829 12:11]: >>> On Fri, Aug 29, 2008 at 6:24 PM, Aidan Van Dyk <aidan@highrise.ca> wrote: >>>> * Perry Wagle <wagle@cs.indiana.edu> [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