On Fri, Feb 28, 2025 at 09:28:21AM -0800, Junio C Hamano wrote: > Junio C Hamano <gitster@xxxxxxxxx> writes: > Subject: BreakingChanges: clarify the procedure > > 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@xxxxxxxxx> > --- > Documentation/BreakingChanges.adoc | 11 +++++------ > 1 file changed, 5 insertions(+), 6 deletions(-) > > diff --git c/Documentation/BreakingChanges.adoc w/Documentation/BreakingChanges.adoc > index 042709a461..bdfad29d8a 100644 > --- c/Documentation/BreakingChanges.adoc > +++ w/Documentation/BreakingChanges.adoc > @@ -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 Thanks, the change look sensible to me. Patrick
