Git 3.0, Rust and other timelines

[rimrul]

Git 3.0 will most likely require Rust. This comes with a couple of minor challenges for Git for Windows. While there is no fixed release date for Git 3.0 yet, I'd like to discuss how we want to approach these, so we are prepared for Git 3.0.

ARM64

I don't see any challenges for ARM64, we could probably start building WITH_RUST right now.

Windows 8.1 support

We're currently still supporting Windows 8.1. Rust raised the requirements for the regular *-windows-gnu targets to Windows 10 in version 1.76.

Theoretically we could stick to an older (unmaintained) version. Git currently only requires 1.49 or newer. We'd probably have to build our own mingw-w64-rust package (based on Msys2s old PKGBUILD).

We could also switch to the new tier 3 *-win7-windows-gnu targets available since version 1.86. Being tier 3 targets, rust doesn't guarrantee that these even build. We'd also have to build our own mingw-w64-rust package (based on MSYS2s current PKGBUILD).

We could also drop support for Windows 8.1, but I'm not sure how intertwined our 32-bit MinGit timeline until 2029, VS2019s EOL in 2029 and Git Credential Managers Windows 8.1 Support until 2029 are.

32-bit support

There are efforts in MSYS2 to drop the 32-bit *-windows-gnu targets. Our options in that case are pinning an old (i.e. before the dropping) rust version or building our own mingw-w64-rust package.

@dscho @mjcheetham , what are your thoughts?

[rimrul]

GCM are adjusting their Windows 8.1 timeline

This is planned to be the last release major release that supports Windows 7 and 8.x. We will be moving off of .NET Framework to .NET (Core) on Windows this year.

[mjcheetham]

Correct. Our plan for Windows 8.1 - for VS2019's sake and usage - is to provide a special release branch, release/v2.7 (exact name undecided) and make only security releases until 2029.

[mjcheetham]

Given Git for Windows is providing a specific MinGit i686 package, fixed to an older MSYS2 runtime, for VS to consume, could we not also apply the same plan for Windows 8.1 support, in that only 32-bit MinGit will support Windows 8.1, and will forever be a Git 2.x release? Git 3.x requiring Rust and Win10+ (and 64-bit Intel/ARM).

[dscho]

I think I'm pretty settled on this plan: With Git 3.0, Git for Windows will only support Windows 10, via x64 and arm64 variants. There will be a last MinGit v2.x release train that will be maintained as best as we can until 2029.

This also allows us to switch to UCRT builds even for x64, which we'll need to do sooner or later anyway because MSYS2 deprecated MINGW64.

[rimrul]

I've done some prep work for the UCRT switch that should allow us to start building UCRT64 packages and deploying them to https://github.com/git-for-windows/pacman-repo/ soon.

We'll still need to figure out what exactly we want to do with the git-sdk and setup-git-for-windows-sdk. I know that you've talked about a separate git-sdk repo for UCRT64 in #3167 (comment), but I've been starting to think about maybe doing a ucrt64 branch instead and then "just" switching the default branch when the time comes

[dscho]

Thank you so much for all that work!

I am starting to think that you're right about the same repository, and simply using a new branch. That would definitely make the transition much easier (install all the UCRT64 packages, then remove all the MINGW32/MINGW64 packages, all in one PR's GitHub workflow run).

For the time being, we do not really need any build-installers and/or minimal ci-artifacts, but it should be relatively easy to extend the ci-artifacts workflow to provide and test those, too.

We can totally hack up the setup-git-for-windows-sdk Action to special-case the ucrt64 architecture to handle this; For now, we only need the full flavor to start populating the pacman-repo, right? But we should probably retire the Azure Blobs-backed storage before that, and go all-in on the pacman-repo; With git-for-windows/build-extra#695, the pacman-repo backend reached feature parity with the Azure Blobs backend, as it is now relatively straight-forward to determine present and past package versions' locations.

One important thing I forgot so far: We need to pre-announce the shift to UCRT64 (i.e. losing Windows 8.1 support unless the UCRT is specifically installed, which is not the default and does not come as part of a regular Windows Update). And we need to do that soon, as we're less than a week away from v2.55.0-rc0.

[rimrul]

losing Windows 8.1 support unless the UCRT is specifically installed, which is not the default and does not come as part of a regular Windows Update

With Git 3.0, unless we want to build our own rust package we'll lose Windows 8.1 support, full stop. I'm not sure it makes sense to announce a separate ucrt64 switchover before that.

[dscho]

True. We should, however, warn Windows 8.1 users, in the release notes of Git for Windows v2.55, that support for their platform is on its way to retirement.

[rimrul]

We'll also need to keep an eye on msys2/MINGW-packages#29327

[dscho]

Thank you so much, I had totally missed this!

[dscho]

In gitgitgadget#2213, I attempt to address building with Rust in Git's Windows CI jobs.