Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> writes: > It seems pretty haphazard to me, is it even documented somewhere? > > I'm talking about an establish process backed up by code, where for > example I can add an experimental feature in v2.14.0, it'll be subject > to change & warn unless you configure core.use_experimental=true or > whatever until v2.16.0, then it'll be considered stable, and changing > the semantics of any stable feature will require opt-in configuration > that'll only become default after N more release cycles where N is > some well-defined number. > > Git's deprecation cycles, such as they are, seem to be better > described as: it'll be noted in the release notes or docs, then left > for some indeterminate amount of time until we have the argument on a > case-by-case basis of if/when/how to deal with that specific case. I do not think we have any "Statutory law" about how to make a backward-incompatible change in Documentation/; I do not terribly mind if we see some write-up on the topic there. Having said that, after getting burned by "git-foo no longer is on your $PATH" change in 1.6 era [*1*], I think we have been pretty good at following the same pattern to ease the pain to the users during transition each time we had to introduce a change that forces existing users to adjust to the new world order. Recall how any of the following (not exhaustive samples) were done: introducing and making the default value of push.default from "matching" to "simple"; removal of "git tar-tree"; "git add -u" working on the whole tree even when run from a subdirectory. We start by issuing warning message when a deprecated feature is used or a feature that will change its default is used, wait for a few releases (depending on how entrenched its use is), and then finally flip the switch and remove the message. You are right to point out that we tend to refrain from setting the timetable from the beginning of the deprecation dance, and it might be a good idea to set the exact cut-off date upfront. I have no strong opinion. [References] *1* https://public-inbox.org/git/?q=gmane:93813