Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

Felipe Contreras wrote:

On Fri, Aug 29, 2008 at 7:24 PM, Aidan Van Dyk [off-list ref] wrote:

quoted

* Felipe Contreras [off-list ref] [080829 12:11]:

quoted

On Fri, Aug 29, 2008 at 6:24 PM, Aidan Van Dyk [off-list ref] wrote:

quoted

* Perry Wagle [off-list ref] [080801 00:00]:

quoted

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