Re: [PATCH v2] BreakingChanges: early adopter option
- From
Patrick Steinhardt <ps@pks.im>
- Date
- Oct 16, 2024, 07:22 UTC
- Message-ID
- <Zw9ppbrFqVN5S50J@pks.im>
- In-Reply-To
- <xmqq1q0mcnt8.fsf@gitster.g>
On Fri, Oct 11, 2024 at 02:49:39PM -0700, Junio C Hamano wrote:
Show 25 quoted lines
> 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!
Patrick