Announce deprecation of 32-bit Git for Windows, define a timeline

[dscho]

Cygwin v3.4.0 already dropped support for i686, and hence Git for Windows won't be able to provide newer 32-bit builds of the MSYS2 runtime as soon as switching away from the v3.3.x train to the v3.4.x train.

This was coming for a long time, and I thought a lot about the best way to keep i686 support in Git for Windows, but I failed to open a ticket to communicate my plans. This is that ticket.

As of time of writing, Git for Windows v2.39.1's 64-bit installer (i.e. targeting x86_64) has been downloaded a little over 1.6 million times, while the 32-bit installer (i.e. targeting i686) has been downloaded just over 80 thousand times. While download numbers do not correspond exactly 1:1 with user numbers, absent any telemetry they are the best indicator we have for assessing what Windows versions Git for Windows' users need to see supported.

Git for Windows does not have telemetry

Why? Well, we cannot do that. Even if it would be really helpful, e.g. to assess what features to focus on.

But there are a few very, very loud opponents to such a thing who always make a right mess whenever an Open Source project tries to even so much as provide an opt-in way to gather some dependable usage numbers. Even if those numbers would help the Open Source projects a lot. But those opponents think they help the Open Source projects better by making loud noises about privacy concerns.

To stave off such totally unproductive exchanges, Git for Windows simply does not have telemetry, not even opt-in, and won't ever have it. And whenever questions come up like "how many users still need 32-bit support, or support for Windows Vista?" we have to guess. Unsatisfying, but it is what it is.

So roughly speaking, we must assume that one i686 version of Git for Windows is installed for every twenty installed x86_64 versions.

This would suggest that it would be premature to completely drop supporting i686 installers. But once we switch to MSYS2 runtime v3.4.x, as mentioned earlier we won't be able to move the i686 variant of Git for Windows along, we will eternally leave those variants with v3.3.x of the MSYS2 runtime.

Proposed timeline

There are four phases to this:

1. Announce the deprecation
2. Move the x86_64-variant of Git for Windows over to MSYS2 runtime v3.4.x, leaving the i686-variant lagging behind
3. Stop providing i686 builds of Git for Windows, except for MinGit
4. Stop providing i686 builds of Git for Windows altogether

For phase 2, I propose to declare Git for Windows v2.40.x to be the last to fully support i686 builds. I will try my best to determine whether this serves Git for Windows' users well enough.

The need for phase 3 (build only 32-bit MinGit but no other official 32-bit artifacts) arises due to some applications bundling 32-bit MinGit, such as Visual Studio 2019, which is supported until April 10th, 2029.

With this information, I intend to announce the deprecation as soon as possible.

As to phases 3/4: I do not want to render myself into a corner by setting a fixed date prematurely, but my gut feeling is that for the start of phase 3, "some time in 2025" should sound like a sensible timeline to aim for.

Action items

• Find the best venue to figure out how many users actually need i686 support
  ↳ We heard back from Visual Studio, who need to service Visual Studio 2019 (that ships with a 32-bit MinGit) until April 10th 2029
  ↳ Our best bet is probably the announcement in the release notes combined with the warning in the installer
• Phase 1 (leading up to Git for Windows v2.40.0)
  • Add the deprecation to the release notes
  • Add a deprecation message to the installer that pops up whenever Git for Windows is installed on a 32-bit Windows
    • For users installing a 32-bit Git for Windows on a 64-bit Windows, we should strongly advise to install the 64-bit variant of Git for Windows instead.
• Phase 2 (after Git for Windows v2.40.0)
  • We will need to split off a msys2-runtime-3.3, once again following MSYS2's lead
  • Git for Windows' automation will need to be taught to build MSYS2 runtime v3.3.x for i686, the other versions for x86_64
  • The /deploy command of the GitForWindowsHelper GitHub App will need to be taught to special-case the packages msys2-runtime and msys2-runtime-3.3, starting only an x86_64 build for the former and only an i686 build for the latter
  • git-sdk32 needs to move from msys2-runtime to msys2-runtime-3.3.
  • msys2-runtime needs to upgrade to v3.4.*
• Phase 3 (some time in 2025)
  • We will want to limit the git-artifacts workflow for the i686 architecture to build only MinGit (not even BusyBox-based MinGit)
  • We will want to adjust Git for Windows' home page to no longer suggest downloading the 32-bit installer.
  • The check-for-missing-dlls workflows in build-extra and git-sdk-32 need to run only for MinGit
• Phase 4 (some time in 2029)
  • We will need to drop the 32-bit parts of the check-for-missing-dlls and main workflows in build-extra
  • we will need to stop building i686 variants of all packages, i.d. once again modify the /deploy command
  • We will want to drop i686 support from git-for-windows-automation's workflows
  • We will need to stop setup-git-for-windows-sdk from supporting the i686 architecture altogether
  • We will want to retire (read: archive) the git-sdk-32 repository

[rimrul]

So roughly speaking, we must assume that one i686 version of Git for Windows is installed for every twenty installed x86_64 versions.

Dropping support for Windows 7/8 will likely also shift that ratio further appart.

Edit: we seem to be starting phase 2 before we drop Windows 7/8

For phase 2, I propose to declare Git for Windows v2.40.x to be the last to fully support i686 builds.

So 2.41.0 will be the expected start of phase 2?

• Add a deprecation message to the installer that pops up whenever Git for Windows is installed on a 32-bit Windows

We might also want a different deprecation notice for users installing 32 bit Git for Windows on a 64 bit OS, recommending they install the 64 bit version instead.

[dscho]

we seem to be starting phase 2 before we drop Windows 7/8

Yes. Given that the next MSYS2 runtime version jump will get us outside of i686 land, and only the next jump after that will get us outside of Windows 7 land, I would say that we have to do that.

For phase 2, I propose to declare Git for Windows v2.40.x to be the last to fully support i686 builds.

So 2.41.0 will be the expected start of phase 2?

That's my current thinking. I am open to arguments in favor or against that.

• Add a deprecation message to the installer that pops up whenever Git for Windows is installed on a 32-bit Windows

We might also want a different deprecation notice for users installing 32 bit Git for Windows on a 64 bit OS, recommending they install the 64 bit version instead.

Oh yes, very good idea!

[rimrul]

So the preliminary timeline is

• Start of phase 1 of i686 deprecation: now
• Start of phase 2 of i686 deprecation: Git 2.41.0 (may 2023)
• Full deprecation of Windows 7/8: first release after Cygwin 3.5 (late 2023)
• Full deprecation of i686: 2025

[dscho]

So the preliminary timeline is

* Start of phase 1 of i686 deprecation: now

* Start of phase 2 of i686 deprecation: Git 2.41.0 (May 2023)

* Full deprecation of Windows 7/8: first release after Cygwin 3.5 (late 2023)

* Full deprecation of i686: 2025

Yes. Does that sound good to you?

[rimrul]

Looking at just the numbers, it looks like we're rushing phase 1 and dragging our feet on phase 3, but knowing how the numbers came to be, I'd say that's okay.

[mjcheetham]

Full deprecation of [..]

Just to confirm, this means actively blocking installation or no produced binaries?

[rimrul]

For Windows versions this means raising the minimum required version in the installer, including a msys2-runtime based on cygwin 3.5, and preparing for use of newer APIs and for potentially dropping compatibility code.

For i686, it means archiving git-sdk-32 and not producing binaries anymore.

[dscho]

I found out that we probably need to insert a phase 2.5 because apparently there is one user of i686 MinGit who needs support until 2029: Visual Studio.

[rimrul]

2029? That's quite the extension of our timeline. What degree of support are we talking about?

[bricss]

It would be easier to gift 🎁 brand new x64 machine to that one user 😄 as counter measure from the pain of extended support 😁

[dscho]

It would be easier to gift 🎁 brand new x64 machine to that one user 😄 as counter measure from the pain of extended support 😁

That one user ("Visual Studio") is actually an application that is used by millions of human users. @bricss if you have the kind of cash as to gift all of those users x64 machines, I would gladly take that money in return for extending the 32-bit support to 2029.

2029? That's quite the extension of our timeline. What degree of support are we talking about?

@rimrul since Visual Studio bundles MinGit only, that's what I would try to limit phase 2.5 to. Like, stop building 32-bit installers, portable Git and .tar.bz2 archive (and for good measure, BusyBox-based MinGit), but still produce a MinGit targeting i686 processors.

[proxy-m]

Please, fix cygheap/msys2/fork bash issues before starting deprecation process! As I can see it does not depend on 32/64-bits.

#4388

#4375

#4373

[dscho]

Please, fix cygheap/msys2/fork bash issues before starting deprecation process! As I can see it does not depend on 32/64-bits.

#4388

#4375

#4373

It is not reasonable to ask for such a big undertaking when we entered the maintenance mode of 32-bit Git for Windows. The cygheap issues are relevant only when the i686 variant of the MSYS2 runtime is used, and most often occur when used interactively.

Since the vast majority of setups out there support running the x86_64 variant of Git for Windows, the only remaining relevant concern might be MinGit (i686), as it is used by Windows applications that still need to support both x86_64 and i686 setups, such as Visual Studio. However, most scenarios where MinGit is used do not even involve the MSYS2 runtime (running most Git operations via git.exe does not require the MSYS2 runtime), and those that do are using it in a non-interactive manner.

All of this is to say: the benefit of pouring resources into the mentioned tickets is so small that it does not justify the cost.

@proxy-m if you care strongly, I encourage you to use your own resources to work on this, i.e. your time and skill. I will be glad to merge any correct PR you open to fix those bugs.

[dscho]

https://gitforwindows.org/32-bit.html already announced the timeline.