Felipe Contreras wrote:
On Fri, Aug 29, 2008 at 7:24 PM, Aidan Van Dyk <aidan@xxxxxxxxxxx> wrote:
* Felipe Contreras <felipe.contreras@xxxxxxxxx> [080829 12:11]:
On Fri, Aug 29, 2008 at 6:24 PM, Aidan Van Dyk <aidan@xxxxxxxxxxx> wrote:
* Perry Wagle <wagle@xxxxxxxxxxxxxx> [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@xxxxxx
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
