Re: [PATCH v2] BreakingChanges: early adopter option

[Taylor Blau <me@ttaylorr.com>]

On Wed, Oct 16, 2024 at 09:22:13AM +0200, Patrick Steinhardt wrote:
> On Fri, Oct 11, 2024 at 02:49:39PM -0700, Junio C Hamano wrote:
> > diff --git a/Documentation/BreakingChanges.txt b/Documentation/BreakingChanges.txt
> > index 2b64665694..eeb26c9155 100644
> > --- a/Documentation/BreakingChanges.txt
> > +++ b/Documentation/BreakingChanges.txt
> > @@ -59,10 +59,29 @@ over time. If circumstances change, an earlier decision to deprecate or change
> >  something may need to be revisited from time to time. So do not take items on
> >  this list to mean "it is settled, do not waste our time bringing it up again".
> >
> > +== Procedure
> > +
> > +Discussing the desire to make breaking changes, declaring that breaking
> > +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.
> > +
> > +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.
> > +
>
> Agreed. In fact, I'd even tighten the last part a bit: once we have any
> breaking changes queued in the tree, we MUST have a CI job that
> exercises things regularly.
>
> Other than that this looks good to me, thanks!

Thanks, both. Let's start merging this one down.

Thanks,
Taylor