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

Duy Nguyen [off-list ref] writes:

quoted

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