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

x/build: decide what Windows ARM64 version to release 1.18 with #51085

Closed
heschi opened this issue Feb 8, 2022 · 13 comments
Closed

x/build: decide what Windows ARM64 version to release 1.18 with #51085

heschi opened this issue Feb 8, 2022 · 13 comments
Labels
Builders NeedsFix release-blocker
Milestone

Comments

@heschi
Copy link
Contributor

@heschi heschi commented Feb 8, 2022

We now have Windows 10 and 11 running on ARM64. Decide which version to build the 1.18 release on.

In favor of Windows 10: building on an older version effectively guarantees backward compatibility with that version. In favor of 11: we have very limited resources to run Windows ARM64 and we can't get rid of the 10 builders until we've stopped using them for releases.

@gopherbot gopherbot added the Builders label Feb 8, 2022
@heschi
Copy link
Contributor Author

@heschi heschi commented Feb 8, 2022

cc @golang/release

@gopherbot gopherbot added this to the Unreleased milestone Feb 8, 2022
@heschi heschi added NeedsDecision release-blocker labels Feb 8, 2022
@heschi heschi removed this from the Unreleased milestone Feb 8, 2022
@heschi heschi added this to the Go1.18 milestone Feb 8, 2022
@beoran
Copy link

@beoran beoran commented Feb 9, 2022

From a user point of view I would prefer Windows 10. In many settings upgrading to Windows 11 is not easy.

@heschi
Copy link
Contributor Author

@heschi heschi commented Feb 10, 2022

We're not considering dropping support for Windows 10; we're trying to decide whether to build the release on 10 or 11, assuming that both will produce 10-compatible binaries.

@beoran
Copy link

@beoran beoran commented Feb 11, 2022

Fair enough, but is that assumption true?

@bcmills
Copy link
Member

@bcmills bcmills commented Feb 11, 2022

we have very limited resources to run Windows ARM64 and we can't get rid of the 10 builders until we've stopped using them for releases.

If we're not dropping support for Windows 10, then it seems to me that we also shouldn't drop the builders for it. If we're supporting a range of versions, I would think that we would get the most value from testing against the newest and oldest versions in that range.

(It's unfortunate that the builders are so resource-limited, but if we can't afford to run a builder for the older version at all then we probably shouldn't be claiming to support it either.)

@dmitshur
Copy link
Contributor

@dmitshur dmitshur commented Feb 11, 2022

If we're not dropping support for Windows 10, then it seems to me that we also shouldn't drop the builders for it.

This is generally true, resources permitting.

My understanding of the trade-off being considered in this issue is when the builder stops being needed in the future, whether it can be dropped right away or after a year (while it's still used by older Go releases). To expand:

  • If a Windows 11 builder is used for releases, when Windows 10 stops being supported, its builder can be dropped right away.
  • If a Windows 10 builder is used for releases, when Windows 10 stops being supported, then we either need to wait for 2 more releases (1 year) to come out before we can drop the builder, or need to modify the major Windows version of the builder used for releases during a minor Go release.

@bcmills
Copy link
Member

@bcmills bcmills commented Feb 11, 2022

Hmm, I think I understand that reasoning.

Technically we should probably keep running a Windows 10 builder for the development branches that support it even if it isn't being used to cut the release, but the risk of a version-specific regression on a development branch seems low, so a high cost of keeping the builder running might merit a faster turndown at that point.

@heschi
Copy link
Contributor Author

@heschi heschi commented Feb 11, 2022

There's also a risk that the Windows 10 builder will self-destruct, and since Microsoft is not producing new versions of Windows 10 ARM64 we may not be able to replace it.

@alexbrainman
Copy link
Member

@alexbrainman alexbrainman commented Feb 11, 2022

Just FYI.

Notes of a Windows user. Not an average user, but still.

I have not seen any Windows ARM64 PC yet.

I have not seen any Windows 11 PC yet.

Majority of users use Windows 10.

I use Windows 7. Because some of my users also use Windows 7, and I want to feel their pain. My Windows 7 still gets regular updates from Microsoft (every few weeks).

Windows 10 have special page that displays if your computer is good enough to upgrade to Windows 11. I suspect majority of PCs cannot be upgraded. Even latest versions of Windows 10 are unusable if you don't have SSD disk.

There are different versions of Windows 10

https://en.wikipedia.org/wiki/Windows_10#Updates_and_support

My Windows 10 gets upgraded regularly - every few months. Microsoft are pretty forceful about upgrading my Windows 10.

I always wandered how our Windows builders gets upgraded. I suspect they never gets upgraded, because upgrading involves manual button clicking and restarting OS. If that is the case, we should upgrade our builders somehow. I am certain Google cloud offers up to date OS images as time goes, but we don't take this path. Our Windows builder OS images are built from predefined old Google cloud images. Perhaps we should rebuild and redeploy these images regularly. These upgrades are more important than Windows 10 vs Windows 11 debate.

I also wonder if our Windows builder images can be pre-configured to remove more programs, to give more CPU / memory / IO to useful work. Disabling antivirus software gives most benefit for me.

Alex

@heschi
Copy link
Contributor Author

@heschi heschi commented Feb 11, 2022

@alexbrainman Thanks for the notes. I don't understand what they have to do with how to decide what version of Windows ARM64 to use. There was never a version of Windows 7 for ARM64, and my understanding is that Windows 10 for AM64 is no longer maintained unless you pay for Windows IOT LTSC. If you want there to be a particular decision about which version to use, I don't understand what it is. If you want something happen for the AMD64 or 386 Windows builders, please file a new issue.

@alexbrainman
Copy link
Member

@alexbrainman alexbrainman commented Feb 13, 2022

I don't understand what they have to do with how to decide what version of Windows ARM64 to use.

I just dumped my brain here. Sorry for hijacking the issue. Feel free to ignore my notes.

But IMHO there are very few users of Windows ARM64. So it does not matter what type of builder you will have. As long as the builder passes all tests, that should be good enough.

There was never a version of Windows 7 for ARM64, and my understanding is that Windows 10 for AM64 is no longer maintained unless you pay for Windows IOT LTSC. If you want there to be a particular decision about which version to use, I don't understand what it is.

Like I said above, I have 0 knowledge of Windows ARM64 history and current use. So I would defer to whatever decision you will make.

If you want something happen for the AMD64 or 386 Windows builders, please file a new issue.

None of the issues I mentioned affect me. It is Go team hardware and test environment. So I will let you decide how to run the hardware and what versions of Windows to test.

Alex

@heschi
Copy link
Contributor Author

@heschi heschi commented Feb 14, 2022

We've decided to try Windows 11 for RC1. If it causes trouble we can change our mind for the final release.

@dmitshur dmitshur added NeedsFix and removed NeedsDecision labels Feb 14, 2022
@gopherbot
Copy link

@gopherbot gopherbot commented Feb 14, 2022

Change https://go.dev/cl/385714 mentions this issue: cmd/release: build 1.18 windows-arm64 on Windows 11

@cagedmantis cagedmantis added this to Done in Go Release Team Mar 1, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Builders NeedsFix release-blocker
Projects
Development

No branches or pull requests

6 participants