From: "brian m. carlson" <sandals@crustytoothpaste•net>
To: Taylor Blau <me@ttaylorr•com>
Cc: Patrick Steinhardt <ps@pks•im>, 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, 16 Oct 2025 21:32:41 +0000 [thread overview]
Message-ID: <aPFkeZrowzxtg6uN@fruit.crustytoothpaste.net> (raw)
In-Reply-To: <aObgEGjcou06nP68@nand.local>
[-- Attachment #1: Type: text/plain, Size: 2773 bytes --]
On 2025-10-08 at 22:05:04, Taylor Blau wrote:
> 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.
I agree that it would be appropriate to be somewhat flexible. My
personal view is that we should inform stakeholders relatively soon
(preferably within the next month) and expect them to promptly and
diligently undertake the necessary work to get started (maybe within
another month) and provide a rough roadmap.
If that happens, I expect most stakeholders will be done in about a year
to a year and a half, tops. Assuming a reasonable release cycle, I
think it should be fine to give people some grace to do a release with
those changes as long as they can communicate a reasonable timeline to
us and show that they're making a reasonably diligent effort.
I also think there will be some stakeholders, probably including some
forges, that will not promptly undertake the work. In my view, the
answer then is that we won't consider their readiness as affecting our
timeline.
There are also some implementations that I know already have SHA-256
support. I believe libgit2 and Forgejo both have at least some
functionality there, so we may want to just give them a heads up that
they may want to polish any support they have before Git 3.0.
If we want to set a hard cap, then I'd say two years. I know that's
what we said in 2024, but we didn't communicate it well at the time.
What I have been communicating elsewhere is that Git 3.0 is tentatively
planned for a year from now, so that may be a good initial phrasing to
set expectations, with the clarifications we've specified. I think a
year from now would be good if all the relevant stakeholders are
finished before then (which is possible, but unlikely).
--
brian m. carlson (they/them)
Toronto, Ontario, CA
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 262 bytes --]
next prev parent reply other threads:[~2025-10-16 21:32 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
2025-10-16 21:32 ` brian m. carlson [this message]
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=aPFkeZrowzxtg6uN@fruit.crustytoothpaste.net \
--to=sandals@crustytoothpaste$(echo .)net \
--cc=ben.knoble@gmail$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
--cc=luca.milanesio@gmail$(echo .)com \
--cc=me@ttaylorr$(echo .)com \
--cc=ps@pks$(echo .)im \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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