Open dmitshur opened 4 years ago
/cc @cagedmantis
The @golang/release team has considered the current builders, and we are proposing the following builder changes for the Go 1.16 release:
Builder Name | Host Type | |
---|---|---|
Current | linux-amd64-jessie | host-linux-jessie |
New | linux-amd64 | host-linux-stretch |
(Or rather a new builder, identical to the linux-amd64
one, just named linux-amd64-stretch
instead.)
Rationale: Debian 8 "Jessie" Long Term Support (LTS) has ended on June 30, 2020 (see https://wiki.debian.org/LTS). We want to start using the next stable release, Debian 9 "Stretch", which has LTS support until June 2022.
Note that this has caused #31293 in April 2019 when this change was made unintentionally as part of a minor release, and it was reverted. We hope that it should be okay to try again for Go 1.16 a year later, since this is being done intentionally this time, and for a major release. CC @ianlancetaylor, @jayconrod, @bradfitz.
Builder Name | Host Type | |
---|---|---|
Current | linux-386 | host-linux-jessie |
New | linux-386-stretch | host-linux-stretch |
Rationale: Same as the one above for linux/amd64.
Builder Name | Host Type | |
---|---|---|
Current | linux-arm | host-linux-arm-scaleway |
New | linux-arm-aws | host-linux-arm-aws |
Rationale: The replacement builder has proven to be more reliable, and it is easier for us to maintain.
Builder Name | Host Type | |
---|---|---|
Current | linux-arm64-packet | host-linux-arm64-packet |
New | linux-arm64-aws | host-linux-arm64-aws |
Rationale: The replacement builder has proven to be more reliable, and it is easier for us to maintain.
Also see https://github.com/golang/go/issues/42304#issuecomment-719803684.
Feedback is welcome: we are happy to alter the plan based on information we haven't already considered. These builder changes are planned for Go 1.16 Beta 1, and we will re-evaluate this as needed based on any new findings and feedback.
Change https://golang.org/cl/276034 mentions this issue: cmd/release, dashboard: implement builder plan for Go 1.16
CL 276034 has implemented the aforementioned plan for Go 1.16.
We'll need to revisit this issue next time during the Go 1.17 development cycle. (If we discover problems with the Go 1.16 plan, we'll come back here, or file new issues.) Moving to the next milestone for now.
While working on issue #39326, it has become clear to me that the C compile we have installed on our windows gomotes (at least the ones I have used) is pretty ancient -- GCC 5. It would be great if we could update the version to something a bit more recent (V10 maybe). Also worth noting that many folks are now using clang instead of gcc on windows -- it would be great if our gomotes had clang available as well.
@thanm Can you please file a separate issue to track that work, and CC @golang/release? It may need more information/investigation. Thanks.
Filed https://github.com/golang/go/issues/43195. Thanks.
Change https://golang.org/cl/278357 mentions this issue: cmd/release: update checkRelocations for Go 1.16
Change https://golang.org/cl/313070 mentions this issue: dashboard: make FreeBSD 11.4 and 12.2 builders the default
The @golang/release team has considered the current builders, and we are proposing the following builder change for the Go 1.17 release:
Builder Name | Host Type | |
---|---|---|
Current | freebsd-amd64-11_2 | host-freebsd-11_2 |
New | freebsd-amd64-11_4 | host-freebsd-11_4 |
Rationale: Using the latest "patch" release of the oldest supported "major" release of FreeBSD.
https://github.com/golang/go/issues/45727#issuecomment-825803454
Builder Name | Host Type | |
---|---|---|
Current | freebsd-386-11_2 | host-freebsd-11_2 |
New | freebsd-386-11_4 | host-freebsd-11_4 |
Rationale: Using the latest "patch" release of the oldest supported "major" release of FreeBSD.
https://github.com/golang/go/issues/45727#issuecomment-825803454
Change https://golang.org/cl/315889 mentions this issue: cmd/release: start using the FreeBSD 11.4 builder for Go 1.17
There haven't been noteworthy builder changes in the last 2 weeks since https://github.com/golang/go/issues/40561#issuecomment-830424055. I've looked over our current selection of releaselets for 1.17 once again, and I think it's good to proceed with.
I did spot one opportunity we can consider: to start using darwin-amd64-11_0
(Big Sur) builder for 1.17, in line with our general approach of using latest macOS builders for macOS releases. (And we have the opportunity of testing it during Beta 1).
Let's make a decision on this one entry. Otherwise, I think it's okay to look again for the 1.18 cycle.
We agreed to use darwin-amd64-11_0
for 1.17 onwards, filed #46161 for that, and moving this to 1.18 milestone.
The @golang/release team has considered the current builders, and we are proposing the following builder change for the Go 1.18 release:
Port | Current Builder | Current Host Type | Proposed Builder | Proposed Host Type |
---|---|---|---|---|
freebsd-386 | freebsd-386-11_4 | host-freebsd-11_4 | freebsd-386-12_2 | host-freebsd-12_2 |
freebsd-amd64 | freebsd-amd64-11_4 | host-freebsd-11_4 | freebsd-amd64-12_2 | host-freebsd-12_2 |
windows-386 | windows-386-2008 | host-windows-amd64-2008 | windows-386-2012 | host-windows-amd64-2012 |
windows-amd64 | windows-amd64-2008 | host-windows-amd64-2008 | windows-amd64-2012 | host-windows-amd64-2012 |
Rationale: Using the latest "patch" release of the oldest supported "major" release of FreeBSD. Using the latest supported version of Windows server.
Change https://golang.org/cl/365694 mentions this issue: cmd/release: update the releaselets for go1.18
The @golang/release team has revised the proposed releaselets to be used for the Go 1.18 release:
Port | Current Builder | Current Host Type | Proposed Builder | Proposed Host Type |
---|---|---|---|---|
freebsd-386 | freebsd-386-11_4 | host-freebsd-11_4 | freebsd-386-12_2 | host-freebsd-12_2 |
freebsd-amd64 | freebsd-amd64-11_4 | host-freebsd-11_4 | freebsd-amd64-12_2 | host-freebsd-12_2 |
Rationale: Using the latest "patch" release of the oldest supported "major" release of FreeBSD. The Windows change was removed because of the discussions in #47845 and release team meetings.
Change https://golang.org/cl/368394 mentions this issue: cmd/release: revert to macOS 11 builder for 1.17, 1.16 minor releases
By now we have darwin builders with macOS 12 both on amd64 and arm64 architectures (#49149), though that work is still evolving. We will consider whether to use them or still use macOS 11 for building 1.18 before Beta 1. The current trajectory is to use macOS 12 builder at least for arm64, but that may change. (Feedback on this is welcome.)
Change https://golang.org/cl/369958 mentions this issue: cmd/release: start using macOS 12 releaselets in Go 1.18 Beta 1
We've discussed macOS today and agreed to use macOS 12 releaselets both for amd64 and arm64 architectures starting with Go 1.18 Beta 1. Sent CL 369958.
All looks ready for Go 1.18 Beta 1, so moving this recurring issue to the next milestone.
Change https://golang.org/cl/377474 mentions this issue: dashboard: clean up builders affected by memory corruption
I've updated 1.18 to use FreeBSD 12.3, which has the fix for the memory corruption bug discussed in #49209.
I've looked through our current releaselet selection for 1.18:
darwin/amd64 darwin-amd64-12_0
darwin/arm64 darwin-arm64-12
freebsd/386 freebsd-386-12_3
freebsd/amd64 freebsd-amd64-12_3
linux/386 linux-386-stretch
linux/amd64 linux-amd64-stretch
linux/arm linux-arm-aws
linux/arm64 linux-arm64-aws
linux/ppc64le linux-ppc64le-buildlet
linux/s390x linux-s390x-crosscompile
windows/386 windows-386-2008
windows/amd64 windows-amd64-2008
windows/arm64 windows-arm64-11
In general it is quite up to date and there's not much that needs to (or can) change for 1.19.
For example, we're already using macOS 12 (the latest macOS release today) builders for darwin amd64 and arm64 ports, Windows 11 builder for windows arm64 port. Nothing to do there.
FreeBSD builders were just recently updated from 11.4 to 12.3 in 1.18, so they're in good shape. (FreeBSD 12.x is still supported for some time.)
One opportunity I'm spotting is to update linux 386 and amd64 from Debian Stretch to Debian Buster. We updated to stretch in Go 1.16, and Stretch is documented to exit its LTS support on June 30, 2022. (Go 1.19 final is aiming for August 2022.) Buster is supported July 2022 to June 2024.
The linux arm and arm64 ports use the AWS builders which are already running buster, so they don't need any changes.
So my only change suggestion for 1.19 that we can consider is:
linux/386 linux-386-stretch → linux-386-buster
linux/amd64 linux-amd64-stretch → linux-amd64-buster
Change https://go.dev/cl/410094 mentions this issue: internal/releasetargets: update linux-{386,amd64} builders to buster
CL 410094 makes Go 1.19 start using the buster builder as mentioned above.
There's nothing more planned to do here at this time, moving to next milestone.
Change https://go.dev/cl/445619 mentions this issue: dashboard,internal/releasetargets: target Bullseye for Go 1.20
Change https://go.dev/cl/449615 mentions this issue: all: replace linux-arm64-aws with linux-arm64
Change https://go.dev/cl/453956 mentions this issue: dashboard,internal/releasetargets: run AMD64 Macs AWS, build 1.20 with 13
Current state of affairs is visible at https://cs.opensource.google/go/x/build/+/master:internal/releasetargets/releases.txt;l=105;drc=14add1f2a409547572304844b265b007589d3c16.
Linux: We've updated most of the linux builders to Bullseye, but I suspect not arm-aws, and I'm not sure of the state of arm on GCE (@cagedmantis).
macOS: We've updated AMD64 to 13, but don't have an ARM64 13 builder yet. That's slightly unfortunate but I don't think it's a major problem.
Windows: seems like we want to be on 2008 for as long as that's our minimum supported version?
FreeBSD: should probably be updated to 13.
Anything I'm missing?
linux-arm-aws
is currently on Buster. We do not have immediate plans to deploy a replacement on GCE nor do we plan to update the current image.
Change https://go.dev/cl/454936 mentions this issue: internal/releasetargets: use FreeBSD 13 for Go 1.20
Nothing else to do this cycle, bumping.
Linux: bullseye is still the latest version. linux-arm-aws is still behind and we're still okay with it. macOS: 13 is still the latest version, so we're good on AMD64 and still behind on ARM64. I think we're still okay with it. Windows: we've dropped support for Windows 8 -- we need to target windows-386/amd64-2016. Windows 11 is still the most recent major version on ARM64, though it's an old patch level by now. FreeBSD: should perhaps be updated to 13.2 but it's a second-class port and not our problem.
Change https://go.dev/cl/495317 mentions this issue: internal/releasetargets: target Windows 2016
Done for this cycle.
Change https://go.dev/cl/503755 mentions this issue: internal/releasetargets: drop Go 1.18 targets
Change https://go.dev/cl/503758 mentions this issue: internal/releasetargets: set LongTestBuilder for darwin-amd64
Change https://go.dev/cl/503756 mentions this issue: internal/releasetargets: regenerate all ports for Go 1.21
Change https://go.dev/cl/504525 mentions this issue: internal/releasetargets: set LongTestBuilder for linux-arm64
Change https://go.dev/cl/527017 mentions this issue: internal/releasetargets: drop Go 1.19 targets
Change https://go.dev/cl/547935 mentions this issue: internal/releasetargets: regenerate all ports for Go 1.22
CL 547935 takes care of the port list for Go 1.22.
After Go 1.22.0 is out, all release artifacts we produce will be via reproducible cross-compilation and distpack, so the work of "evaluate the choice of releaselets (builders that are used for constructing a release artifact)" that this issue tracks becomes obsolete. We still need to handle the port list, though it'll be possible to replace its generation with a run-time computation if that's easier. And the releasetargets package can be simplified. We do still need to continuously maintain and update OS versions, but that's out of scope for here.
Dealing with all that is for after Go 1.22.0 is out, so moving this to the next milestone to revisit later.
Change https://go.dev/cl/564217 mentions this issue: internal/releasetargets: update MinMacOSVersion for Go 1.23
Change https://go.dev/cl/564216 mentions this issue: internal/releasetargets: drop Go 1.20 release targets
Change https://go.dev/cl/564255 mentions this issue: internal/releasetargets: delete fields not relevant to distpack releases
Change https://go.dev/cl/585216 mentions this issue: internal/releasetargets: add openbsd/ppc64 target for Go 1.22 onwards
Change https://go.dev/cl/588137 mentions this issue: internal/releasetargets: regenerate all ports for Go 1.23
Done for the Go 1.23 cycle.
Change https://go.dev/cl/612555 mentions this issue: internal/releasetargets: drop 1.21 targets, add 1.24 targets
At the start of each code freeze, we should evaluate the choice of releaselets (builders that are used for constructing a release artifact) used to make the upcoming major Go release, and confirm they are the most appropriate choice out of what is available.
The start of a code freeze is a safe time to introduce a builder change, as it will be tested during pre-release versions, starting with beta 1 and onwards.
Making this a release blocker for Go 1.16 (and not okay after beta 1—it needs to be done before). Once completed, this issue should be moved to the next major release milestone.
Edit: Starting with Go 1.21, releaselets are only used for running tests. Release artifact construction happens by reproducibly cross-compiling a distpack distribution on a fixed builder.
CC @golang/release, @ianlancetaylor.