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

Re: When should we release Git 3.0?

From
Patrick Steinhardt <ps@pks.im>
Date
Oct 9, 2025, 05:59 UTC
Message-ID
<aOdPXrELgKkxVLSp@pks.im>
In-Reply-To
<aObgEGjcou06nP68@nand.local>
On Wed, Oct 08, 2025 at 06:05:04PM -0400, Taylor Blau wrote:
Show 29 quoted lines
> On Tue, Oct 07, 2025 at 12:27:16PM +0200, Patrick Steinhardt wrote:
> > Yeah, it's definitely my goal here to do exactly that: reach out to
> > folks and take everyone's input into account. Once we've got it, propose
> > a timeline.
> >
> > I guess as part of that initial communication with the stakeholders we
> > can also mention that the current plan is to release roughly towards the
> > end of next year, which may help to put things into perspective.
> 
> I am not sure what our proposal would be other than max(proposed_dates),
> clamped to some reasonable range that we are comfortable with so as not
> to delay the transition to use SHA-256 by default too far into the
> future.
> 
> I think a more interesting question is:
> 
>  - What do we do for implementations that do not have a roadmap, or
>    whose roadmap is too far into the future?
> 
>  - What do we do for implementations that have a roadmap, have a date
>    that is palatable to the project, but end up slipping and are unable
>    to meet that date?
> 
> I generally agree that we have to draw a line in the sand *somewhere*,
> but I don't think we should be so inflexible as to say "if you don't
> have SHA-256 done by X date, you are out of luck". Of course, if the
> amended timeline is too far beyond the initial deadline that's one case.
> But if someone is a release cycle or so behind, I think it's reasonable
> that the project should be flexible enough to accommodate that.

Yeah, if it's about a small number of releases I definitely think we should accommodate for that. But if it's "We'll never have it" or "We'll have it in five years" it's probably a different story.

In any case though, I'd propose to punt on those questions for now and wait for feedback from the impacted communities first. Once we have such feedback we can discuss in more detail.

Patrick
Previous: Taylor BlauNext: brian m. carlson
Message 22 of 33 in “When should we release Git 3.0?”
  1. brian m. carlsonSep 30, 2025
  2. Luca MilanesioOct 1, 2025
  3. Taylor BlauOct 1, 2025
  4. rsbecker@nexbridge.comOct 1, 2025
  5. Taylor BlauOct 8, 2025
  6. rsbecker@nexbridge.comOct 8, 2025
  7. Patrick SteinhardtOct 2, 2025
  8. Junio C HamanoOct 2, 2025
  9. Michal SuchánekOct 2, 2025
  10. Patrick SteinhardtOct 7, 2025
  11. Michal SuchánekOct 7, 2025
  12. Patrick SteinhardtOct 7, 2025
  13. Michal SuchánekOct 7, 2025
  14. Junio C HamanoOct 7, 2025
  15. Michal SuchánekOct 7, 2025
  16. SZEDER GáborOct 8, 2025
  17. Patrick SteinhardtOct 9, 2025
  18. Ben KnobleOct 2, 2025
  19. Patrick SteinhardtOct 7, 2025
  20. rsbecker@nexbridge.comOct 7, 2025
  21. Taylor BlauOct 8, 2025
  22. Patrick SteinhardtOct 9, 2025
  23. brian m. carlsonOct 16, 2025
  24. Taylor BlauOct 8, 2025
  25. brian m. carlsonOct 16, 2025
  26. brian m. carlsonOct 2, 2025
  27. Taylor BlauOct 1, 2025
  28. Michal SuchánekOct 1, 2025
  29. brian m. carlsonOct 1, 2025
  30. Michal SuchánekOct 2, 2025
  31. Michal SuchánekOct 2, 2025
  32. Junio C HamanoOct 1, 2025
  33. brian m. carlsonOct 1, 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.