Re: Re* [PATCH v2] BreakingChanges: early adopter option

[Patrick Steinhardt <ps@pks.im>]

On Fri, Feb 28, 2025 at 09:28:21AM -0800, Junio C Hamano wrote:
> Junio C Hamano <gitster@pobox.com> 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@pobox.com>
> ---
>  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