git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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
Previous: Junio C HamanoNext: Taylor Blau
Message 10 of 14 in “BreakingChanges: early adopter option”
  1. BreakingChanges: early adopter optionJunio C Hamano, Sep 19, 2024
  2. Junio C HamanoSep 20, 2024
  3. Junio C HamanoSep 22, 2024
  4. Patrick SteinhardtSep 26, 2024
  5. Phillip WoodSep 26, 2024
  6. Junio C HamanoSep 26, 2024
  7. Junio C HamanoSep 26, 2024
  8. Junio C HamanoSep 26, 2024
  9. BreakingChanges: early adopter optionJunio C Hamano, Oct 11, 2024
  10. Patrick SteinhardtOct 16, 2024
  11. Taylor BlauOct 16, 2024
  12. Re* [PATCH v2] BreakingChanges: early adopter optionJunio C Hamano, Feb 28, 2025
  13. Patrick SteinhardtMar 3, 2025
  14. Junio C HamanoMar 3, 2025

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.