Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

build: announce end of support for old Windows releases #52188

Open
cagedmantis opened this issue Apr 6, 2022 · 17 comments
Open

build: announce end of support for old Windows releases #52188

cagedmantis opened this issue Apr 6, 2022 · 17 comments
Labels
Builders x/build issues (builders, bots, dashboards) Documentation NeedsFix The path to resolution is known, but the work has not been done. recurring Issues that should never be closed, but moved to the next milestone once fixed in the current one. release-blocker
Milestone

Comments

@cagedmantis
Copy link
Contributor

Microsoft continuously releases new version of Windows. We should announce end of support for Windows versions as we discover that they are either no longer supported by Microsoft or no longer have any use as a builder.

Relevant recent discussion: #47845

/cc @golang/release

@cagedmantis cagedmantis added Documentation NeedsFix The path to resolution is known, but the work has not been done. release-blocker recurring Issues that should never be closed, but moved to the next milestone once fixed in the current one. labels Apr 6, 2022
@cagedmantis cagedmantis added this to the Go1.19 milestone Apr 6, 2022
@cagedmantis
Copy link
Contributor Author

@zx2c4 The creation of this issue does not signal a plan to drop support. This issue has been created in order to add an explicit step for the consideration of our support stance during each release.

@zx2c4
Copy link
Contributor

zx2c4 commented Apr 6, 2022

Makes sense. One nit though:

as we discover that they are either no longer supported by Microsoft or no longer have any use as a builder.

Windows 7 is basically out of support now by Microsoft. But it's still supported by Chrome. I tried to come up with a reasonable set of criteria for when I should/could drop support for old Windows for my own software, but ultimately I kept coming back to, "if Chrome supports it, why shouldn't I?" I wonder if Go finds itself in a similar situation there too.

@alexbrainman
Copy link
Member

I still use Windows 7 on one of my computers. And I have to install Microsoft updates on it pretty regularly (every week). So there are still enough users for Microsoft to care.

Alex

@dmitshur dmitshur added this to Planned in Go Release Team Apr 12, 2022
@dmitshur
Copy link
Contributor

Adding a data point observed in Git for Windows release notes upcoming breaking changes section:

[...] Around the beginning of 2023, Git for Windows will drop support for Windows 7 and for Windows 8, following Cygwin's and MSYS2's lead (Git for Windows relies on MSYS2 for components such as Bash and Perl).

@dmitshur dmitshur added the Builders x/build issues (builders, bots, dashboards) label May 31, 2022
@dmitshur dmitshur modified the milestones: Go1.19, Go1.20 Jun 1, 2022
@qmuntal
Copy link
Contributor

qmuntal commented Jun 23, 2022

Another data point: .NET support for Windows 7 and 8.1 will end in January 2023: dotnet/announcements#226

@zx2c4
Copy link
Contributor

zx2c4 commented Jun 23, 2022

Only kind of:

We will offer support for Windows Server 2012/R2 throughout .NET 7 and .NET 8

2012R2 is v6.3, like 8.1.

@aclements
Copy link
Member

@thanm recently ran into a problem where it seems recent Windows C toolchains produce binaries that don't run on the Windows 2008 (≈ Windows 7) builder, which is further support for dropping Windows 7. I'm probably summarizing that poorly. Than?

@thanm
Copy link
Contributor

thanm commented Nov 23, 2022

Details for the problem I ran into can be found in #56904. Use case is a bit on the obscure side (external linking + race + windows-amd64-2008 builder). I have to admit that I am not sure exactly what vintage of windows this builder is.

@alexbrainman
Copy link
Member

Details for the problem I ran into can be found in #56904. Use case is a bit on the obscure side (external linking + race + windows-amd64-2008 builder). I have to admit that I am not sure exactly what vintage of windows this builder is.

I suspect windows-amd64-2008 builder runs Windows Server 2008 (search for "Windows Server 2008" in https://en.wikipedia.org/wiki/List_of_Microsoft_Windows_versions ) and Windows Server 2008 is just a Windows Vista (search for "Windows Vista" in https://en.wikipedia.org/wiki/Windows_Server_2008 ).

Windows Vista is a version between Windows XP and Windows 7 (search https://en.wikipedia.org/wiki/List_of_Microsoft_Windows_versions for "Windows Vista").

Windows Vista was never a big / important version of Windows. I doubt there are many Windows Vista users.

Windows 7 is different from Windows Vista.

And the problem @thanm is having is most likely to do with gcc and not Windows. Windows does not come with free C compiler. So Go uses gcc for cgo. So we cannot blame Windows if gcc does not work in some situations / or Windows versions.

I don't think we should drop support of old versions of Windows if gcc does not work there. I doubt many Go Windows users use cgo, and broken gcc does not affect them.

Personally I only have Windows 10 these days. And I don't even use it day to day anymore. So whatever you decide here is fine with me.

Alex

@heschi
Copy link
Contributor

heschi commented Nov 28, 2022

Trouble with the race detector doesn't seem like reason enough to drop a Windows version to me. However, Chrome is dropping Windows 7 and 8.1 support at about the same time Go 1.20 will come out, so maybe the timing is right anyway.

@alexbrainman
Copy link
Member

However, Chrome is dropping Windows 7 and 8.1 support at about the same time Go 1.20 will come out, so maybe the timing is right anyway.

I am not against dropping Windows 7 support in Go 1.20. But what are the benefits of dropping support for the Go Team?

Chrome might have some problems supporting Windows 7. What are the problems with Windows 7 that Go Team have?

Alex

@heschi
Copy link
Contributor

heschi commented Nov 28, 2022

Every first-class port is a drain on our resources to some extent; tests can flake, compilers can be broken as above, running builders costs money. So perhaps we have opposite perspectives: my attitude is that things have to continuously justify their existence, whereas yours is that we should only remove them if they're causing substantial trouble.

Maybe we should be able to declare particular OS versions second-class; if we could do that I'd say that we can just demote 8.1 and lower to second-class and let interested parties such as yourself maintain them.

@alexbrainman
Copy link
Member

Every first-class port is a drain on our resources to some extent; tests can flake, compilers can be broken as above, running builders costs money. So perhaps we have opposite perspectives: my attitude is that things have to continuously justify their existence, whereas yours is that we should only remove them if they're causing substantial trouble.

I don't believe that Windows 7 users report more issues than others. And Go Team does not have Windows 7 builder. So I don't see why Go Team would pick on Windows 7 users. On the other hand it is good marketing for the project when it supports its existing users (while other projects dropping support for their OS).

Alex

@rsc
Copy link
Contributor

rsc commented Nov 30, 2022

As a reminder, from a Go project policy perspective, we've already set the criteria for keeping an operating system supported. That discussion was #19002, and the documented policy is at https://github.com/golang/go/wiki/PortingPolicy#removing-old-operating-system-and-architecture-versions. Quoting that text:

The important considerations when deciding whether to remove support for an old operating system or architecture version are:

  • Availability. If the operating system is no longer distributed or the hardware is no longer manufactured, for example, there's not a clear need to keep it going. For example, Go's ppc64 port no longer supports the IBM POWER5 architecture.
  • Manufacturer support. If the operating system or architecture is no longer supported by its manufacturer, that is a strong signal that a future version of Go can remove support as well. For example, each year, Apple typically issues one new version of macOS and deprecates one old version. Go typically deprecates old macOS versions at the same rate.
  • Actual or expected user base. If there are relatively few users, significant effort to maintain a port may not be worthwhile.
  • Ongoing costs. Ports that require significant ongoing debugging or implementation efforts will be scrutinized more than ports that don't.

When the considerations weigh in favor of removing a port and a proposal is accepted, Go 1.N's release notes will announce that support for a given operating system or architecture will be dropped in Go 1.(N+1).

For Windows, the manufacturer support factor is the most important one.

Since MS has dropped Windows 7, so should we (by announcing in Go 1.20 that it will be removed in Go 1.21).

@heschi
Copy link
Contributor

heschi commented Nov 30, 2022

I had never noticed the "proposal is accepted" part of the policy. Filed #57003 and #57004.

@heschi
Copy link
Contributor

heschi commented Dec 2, 2022

Nothing left to do until the proposals above are processed and we decide what to put in the release notes. OK after RC.

@heschi heschi added the okay-after-rc1 Used by release team to mark a release-blocker issue as okay to resolve either before or after rc1 label Dec 2, 2022
@gopherbot gopherbot removed the okay-after-rc1 Used by release team to mark a release-blocker issue as okay to resolve either before or after rc1 label Dec 7, 2022
@heschi
Copy link
Contributor

heschi commented Dec 21, 2022

I added the release note. Moving to 1.21.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Builders x/build issues (builders, bots, dashboards) Documentation NeedsFix The path to resolution is known, but the work has not been done. recurring Issues that should never be closed, but moved to the next milestone once fixed in the current one. release-blocker
Projects
Status: Planned
Status: No status
Development

No branches or pull requests

10 participants