git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Patrick Steinhardt <ps@pks.im>
To: Taylor Blau <me@ttaylorr.com>
Cc: Ben Knoble <ben.knoble@gmail.com>,
	Luca Milanesio <luca.milanesio@gmail.com>,
	git@vger.kernel.org
Subject: Re: When should we release Git 3.0?
Date: Thu, 9 Oct 2025 07:59:58 +0200	[thread overview]
Message-ID: <aOdPXrELgKkxVLSp@pks.im> (raw)
In-Reply-To: <aObgEGjcou06nP68@nand.local>

On Wed, Oct 08, 2025 at 06:05:04PM -0400, Taylor Blau wrote:
> 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

  reply	other threads:[~2025-10-09  6:00 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-09-30 23:07 When should we release Git 3.0? brian m. carlson
2025-10-01  7:13 ` Luca Milanesio
2025-10-01 16:04   ` Taylor Blau
2025-10-01 19:31     ` rsbecker
2025-10-08 21:44       ` Taylor Blau
2025-10-08 21:55         ` rsbecker
2025-10-02 13:31     ` Patrick Steinhardt
2025-10-02 15:32       ` Junio C Hamano
2025-10-02 16:10         ` Michal Suchánek
2025-10-07 10:27           ` Patrick Steinhardt
2025-10-07 10:36             ` Michal Suchánek
2025-10-07 13:21               ` Patrick Steinhardt
2025-10-07 13:40                 ` Michal Suchánek
2025-10-07 17:11                 ` Junio C Hamano
2025-10-07 17:28                   ` Michal Suchánek
2025-10-08 20:44             ` SZEDER Gábor
2025-10-09  5:56               ` Patrick Steinhardt
2025-10-02 16:54       ` Ben Knoble
2025-10-07 10:27         ` Patrick Steinhardt
2025-10-07 17:36           ` rsbecker
2025-10-08 22:05           ` Taylor Blau
2025-10-09  5:59             ` Patrick Steinhardt [this message]
2025-10-16 21:32             ` brian m. carlson
2025-10-08 21:59       ` Taylor Blau
2025-10-16 21:42         ` brian m. carlson
2025-10-02 22:33   ` brian m. carlson
2025-10-01 16:01 ` Taylor Blau
2025-10-01 16:20   ` Michal Suchánek
2025-10-01 22:16     ` brian m. carlson
2025-10-02 12:13       ` Michal Suchánek
2025-10-02 13:09         ` Michal Suchánek
2025-10-01 20:36   ` Junio C Hamano
2025-10-01 22:42     ` brian m. carlson
  -- strict thread matches above, loose matches on Subject: below --
2025-10-08 19:06 James Frost
2025-10-09  5:30 ` Patrick Steinhardt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aOdPXrELgKkxVLSp@pks.im \
    --to=ps@pks.im \
    --cc=ben.knoble@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=luca.milanesio@gmail.com \
    --cc=me@ttaylorr.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).