Re: Please discuss: what "git push" should do when you do not say what to push?

["Ævar Arnfjörð Bjarmason" <avarab@gmail.com>]

On Sun, Mar 18, 2012 at 19:50, Junio C Hamano <gitster@pobox.com> 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.