On Sun, Mar 18, 2012 at 19:50, Junio C Hamano <gitster@xxxxxxxxx> wrote: > But again, that is not something we have direct control over [...] > ---whoever is doing the locking-out is taking responsibility for > these users who are out of our reach. Firstly I'm all for this change, but I agree with Andrew Sayers that step the deprecation plan is somewhat questionable. I contribute to the perl core and a few years ago we moved to make yearly releases, at the same time we introduced a deprecation cycle saying that if we warn that something will be removed in $YEAR it's kosher to remove it in $YEAR+2. The problem with that approach is that as Andrew points out OS release cycles aren't yearly, so someone might upgrade from $YEAR-2 to YEAR+3 and find that his programs don't compile anymore. Git is similar to Perl in that most of our users don't get Git from us with any regular interval, they just use whatever's packaged by their OS, and in practice: * Most of your users use your program through their OS vendor * OS vendors will upgrade their OS whenever they feel like it. * OS vendors are in all likelyhood not going to backport some deprecation patch or eject it from their build in a manner that makes sense with regard to their release schedule. That sucks, but given that this is how things work I wonder who we're really helping by implementing deprecation warnings from the standpoint of our release cycle, probably not the majority of our users. Most of our users are either never going to see this warning because their OS will skip the whole of steps 2-6, or worse yet their OS might upgrade Git between steps 2-5 and they'll be stuck watching the warning it for 1-6 years, or however long their upstream vendor takes up upgrade. I think a better strategy would be to just announce that we're going to change it, and then just change it without any intermediate steps. That's what this is going to look like anyway to most of our users, and without the danger that our users will be stuck on releases that'll spew warnings about some upcoming change which in reality happened in upstream years ago. We could even use the only way of communicating to everyone involved that something major changed: bump the major version number. -- 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