On Sun, 15 Feb 2009, Jeff King wrote:
On Sun, Feb 15, 2009 at 09:05:33PM -0800, david@xxxxxxx wrote:
I'm not sure I understand your argument here. If you have a machine that
needs to do _exactly_ what you have tested, then wouldn't you be
concerned about upgrading git 1.5.6.5 to (for example) git 1.7? Or since
you are probably looking at a more macro-level, upgrading Debian 5.0 to
Debian 6.0?
two points
1. someone running Debian 5 who then upgrades to Debian 6 should get the
warning, not the refusal, then when they go to Debian 7 the refusal can be
the standard (and substatute redhat enterprise version numbers for debian
if you want)
So people doing major version upgrades of their OS don't need to read
release notes or re-test behavior?
when was the last time you read the release notes for an entire distro?
they will test behavior, but if things that used to work just fail it's
not good.
What about people who skip straight from 5 to 7? It's OK for them not to
see the warning, because two major versions means they should read the
release notes and re-test?
for the 'enterprise distros' you would need to upgrade from 5 to 6 to 7 to
remain supported. if you go directly from 5 to 7 you have been in
unsupported territory for quite some time (probably measured in years).
and it's not a matter of reading the release notes. it's a matter of them
running a version that gives them a warning before you feed them a version
that will cause their existing stuff to fail.
I recognise that not all software is concerned about backwards
compatibility, but if git wasn't concerned with backwards compatibility
and a graceful upgrade process, this thread wouldn't exist.
David Lang
so a warning can go in at any time, but changing the default in a way
that's not backwards compatible needs to be done over a _very_ long
timeframe. so long that it's worth questioning if it's worth changing (as
opposed to either just leaving the warning, or trying to figure out a
different way)
There has been a lot of questioning, and a lot of discussion of
alternatives already. Please check the list archive for some of it.
I don't think there is a timetable set at this point.
-Peff
--
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
