Duy Nguyen <pclo...@gmail.com> writes: >> * 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.
