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

From: Junio C Hamano <gitster@pobox.com>
Date: May 30, 2017, 00:56 UTC
Message-ID: <xmqqwp8zduwd.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <CACsJy8CUpHNDfvN+P7=Jub4+Z281rzExFV9x3_hdVKw6ORUSqQ@mail.gmail.com>

Duy Nguyen <pclouds@gmail.com> writes:

Show 16 quoted lines

>>  * 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.

The difference/orthogonal-ness of what Ævar wants to do and what the extension mechanism wants to do has been covered by others correctly so I won't repeat. But I do agree with you that "run at this version level" is probably less useful than a la carte "I want to enroll in this and that experiment but not the other one".

I also agree with Peff that we should name it as distinctively as the names used by extensions mechaism---we must strongly discourage the latter from being futzed by the end users, while this opt-in thing is very much open to them.