Re: [RFC/PATCH] WIP: add deprecation & experimental process/interface

From: Duy Nguyen <pclouds@gmail.com>
Date: May 29, 2017, 10:23 UTC
Message-ID: <CACsJy8CUpHNDfvN+P7=Jub4+Z281rzExFV9x3_hdVKw6ORUSqQ@mail.gmail.com>
In-Reply-To: <20170527111032.30897-1-avarab@gmail.com>

On Sat, May 27, 2017 at 6:10 PM, Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote:

Show 15 quoted lines

> This is the WIP start of a deprecation & experimental interface to
> git. The goal is to formalize the workflow around deprecating
> features, or around introducing new experimental features.
>
> This is much more idea than code at the moment, but included is an
> example showing how :/ might be deprecated[1] (let's not discuss /if/
> we should do that here, this is just an example).
>
> The plan, subject to RFC feedback is to:
>
>  * Add a new config variable `core.version`. E.g. `core.version =
>    2.14.0` With this the user can specify that they'd like
>    new/experimental features introduced in that version (and below),
>    as well as immediately getting new deprecations added in that
>    version as errors.

We have extensions.* for this purpose (or close to this purpose). I think it's more flexible to go with extensions.* instead of a single "core.version". extensions.* are non-optional though (if a git binary does not understand it, the repo can't be accessed). So it's more about fundamental experiments (like sha256 transition). I'm guessing we can have a "soft" extensions (warn if not understand, instead of die), like what we have in $GIT_DIR/index.

Deprecation via extension.* though may be unintuitive. But I think something along that line (e.g. deprecation.*) might work.

-- 
Duy