eyecatchu/git
1
0
Fork 0
mirror of https://github.com/git/git.git synced 2026-01-22 14:57:18 +09:00
Code Issues Packages Projects Releases Wiki Activity

BreakingChanges: clarify the procedure

Browse Source 
The point behind a compile-time switch is to ensure that we have a
mechanism to hide myriad of backward incompatible changes that may
be prepared and accumulated over time, yet make them available for
testing any time during the development toward the big version
boundary.  Add a few words to stress that point.

Since the document was first written, we have added the CI job that
the document anticipated us to have.  Rephrase to state the current
status.

The discussion in [*1*] made us abandon the "feature.git3" based
runtime switching of behaviour and instead adopt the compile-time
switching mechanism, but a stray sentence about runtime switching
still remained in the final text by mistake.  Remove it.

[Reference]

 *1* https://lore.kernel.org/git/xmqqldzel6ug.fsf@gitster.g/

Signed-off-by: Junio C Hamano <gitster@pobox.com>
Acked-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This commit is contained in:
Junio C Hamano 2025-02-28 09:28:21 -08:00
parent 2454970930
commit c268e3285d
1 changed files with 5 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

11
Documentation/BreakingChanges.txt
View File

@ -66,22 +66,21 @@ changes are made at a certain version boundary, and recording these
decisions in this document, are necessary but not sufficient.
Because such changes are expected to be numerous, and the design and
implementation of them are expected to span over time, they have to
be deployable trivially at such a version boundary.
be deployable trivially at such a version boundary, prepared over long
time.
The breaking changes MUST be guarded with the a compile-time switch,
WITH_BREAKING_CHANGES, to help this process. When built with it,
the resulting Git binary together with its documentation would
behave as if these breaking changes slated for the next big version
boundary are already in effect. We may also want to have a CI job
or two to exercise the work-in-progress version of Git with these
breaking changes.
boundary are already in effect. We also have a CI job to exercise
the work-in-progress version of Git with these breaking changes.
== Git 3.0
The following subsections document upcoming breaking changes for Git 3.0. There
is no planned release date for this breaking version yet. The early
adopter configuration used for changes for this release is `feature.git3`.
is no planned release date for this breaking version yet.
Proposed changes and removals only include items which are "ready" to be done.
In other words, this is not supposed to be a wishlist of features that should