On Sat, May 27, 2017 at 6:10 PM, Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> wrote: > 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