| Message ID | xmqq1q0mcnt8.fsf@gitster.g (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | [v2] BreakingChanges: early adopter option | expand |
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! Patrick
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
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. + + == 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. +is no planned release date for this breaking version yet. The early +adopter configuration used for changes for this release is `feature.git3`. 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
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. We need to make sure that we can implement, test, and deploy such impactful changes. Earlier we considered to guard the breaking changes with a run-time check of the `feature.git<version>` configuration to allow brave users and developers to opt into them as early adoptors. But the engineering cost to support such a run-time switch, covering new and disappearing git subcommands and how "git help" would adjust the documentation to the run-time switch, would be unrealistically high to be worth it. Formalize the mechanism based on a compile-time switch to allow early adopters to opt into the breaking change in a version of Git before the planned version for the breaking change. Signed-off-by: Junio C Hamano <gitster@pobox.com> --- * As we discussed and came to agreement during the review of v1, let's specify this as a build-time knob. Documentation/BreakingChanges.txt | 21 ++++++++++++++++++++- 1 file changed, 20 insertions(+), 1 deletion(-) Interdiff against v1: diff --git a/Documentation/BreakingChanges.txt b/Documentation/BreakingChanges.txt index cc19e03230..eeb26c9155 100644 --- a/Documentation/BreakingChanges.txt +++ b/Documentation/BreakingChanges.txt @@ -68,15 +68,13 @@ 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 configuration -variable, `feature.git<version>` to help this process. Each -individual breaking change must be implemented in such a way that -for a user who has this configuration variable set to true, it goes -in effect even before Git <version>. Note that setting the -configuration to `false` MUST have no effect, either before or AFTER -Git <version>. In other words, this is purely an option to recruit -early adopters and not a mechanism to keep the old behaviour after -the announced version boundary for breaking changes. +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. == Git 3.0