Re: When should we release Git 3.0?

[Patrick Steinhardt <ps@pks.im>]

On Thu, Oct 02, 2025 at 12:54:13PM -0400, Ben Knoble wrote:
> 
> > Le 2 oct. 2025 à 09:33, Patrick Steinhardt <ps@pks.im> a écrit :
> > 
> > On Wed, Oct 01, 2025 at 12:04:38PM -0400, Taylor Blau wrote:
> >> 
> >> 
> >> So my feeling here is that we should take into account not just the
> >> readiness of the underlying Git implementation used by hosting providers
> >> in the Git ecosystem, but also the readiness of the hosting providers
> >> themselves to do the work necessary to facilitate that transition
> >> outside of their Git implementation.
> > 
> > We definitely should take into account the readiness. But what I think
> > we'll need is a roadmap from impacted Git implementations and hosting
> > providers so that we can answer the question when they plan to have
> > SHA256 support ready.
> > 
> > Without such a roadmap it's basically impossible for us to set up any
> > realistic date. In that case, we only have one of two options:
> > 
> >  - We just wait until eventually everyone has SHA256 support. This has
> >    the effect that there is no pressure on anybody, and thus it is more
> >    likely than not that it'll just never happen.
> > 
> >  - We set a strict, "uninformed" deadline that may be too ambitious and
> >    unrealistic.
> 
> This seems like a false dichotomy to me. Of course we can forever
> debate options to go forward, too, so at some point we must have a
> decision :)
> 
> Anyway, what about establishing a strong but adjustable (“proposed”)
> timeline now, based on informed opinions from folks who have already
> provided estimates of what’s required? Then we can shop around for
> input on the proposed deadline while still taking into account new
> information. 
> 
> It also provides impetus: “sans input, we will go forward with the
> proposal, so let us know if you need more time” might motivate folks
> to firm up their own timelines and provide said input.

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.

> > Once we have roadmaps, we should set a strict deadline that takes them
> > into account. Any hosting provider or implementation of Git that doesn't
> > provide a roadmap will not be taken into account in our planning.
> 
> Btw, I’ve often wondered since I see representatives from
> GitHub/GitLab (and JGit/Gerrit to a lesser extent) often prominently
> identified as such: do we have folks from GitTea/SourceHut/other
> smaller forges around on the mailing list to weigh in? I assume we’d
> also like to include their input.

Such smaller forges should definitely be included. My plan is to gather
a list of stakeholders for now and then send an email where we Cc
maintainers of such implementations.

Patrick