* Re: [PATCH 00/11] Start retiring .git/remotes/ and .git/branches/ for good
@ 2017-05-17 0:51 7% ` Junio C Hamano
0 siblings, 0 replies; 1+ results
From: Junio C Hamano @ 2017-05-17 0:51 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason
Cc: Johannes Schindelin, Git Mailing List
Ævar Arnfjörð Bjarmason <avarab@gmail.com> 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
^ permalink raw reply [relevance 7%]
Results 1-1 of 1 | reverse | options above
-- pct% links below jump to the message on this page, permalinks otherwise --
2017-05-11 13:47 [PATCH 00/11] Start retiring .git/remotes/ and .git/branches/ for good Johannes Schindelin
2017-05-12 1:14 ` Junio C Hamano
2017-05-12 10:18 ` Johannes Schindelin
2017-05-16 0:37 ` Junio C Hamano
2017-05-16 8:05 ` Ævar Arnfjörð Bjarmason
2017-05-16 9:06 ` Junio C Hamano
2017-05-16 10:02 ` Ævar Arnfjörð Bjarmason
2017-05-17 0:51 7% ` Junio C Hamano
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).