#3023 Change: Golang1.21
Closed: Accepted 2 years ago by zbyszek. Opened 2 years ago by amoloney.

Update of Go (golang package) to the upcoming version 1.21 in Fedora 39.

Owners, do not implement this work until the FESCo vote has explicitly ended.
The Fedora Program Manager will create a tracking bug in Bugzilla for this Change, which is your indication to proceed.
See the FESCo ticket policy and the Changes policy for more information.

REMINDER: This ticket is for FESCo members to vote on the proposal. Further discussion should happen in the devel list thread linked above.


It seems like I missed this announcement on the devel list ... the proposal says it will require a mass rebuild of all Go packages (obviously), but that golang 1.21 will only be released in August, while the Fedora 39 mass rebuild will happen in two weeks (starting July 19, at least according to the schedule). Does this mean we will have a golang 1.21 beta / pre-release in time for the f39 mass rebuild, or will there be a targeted mass rebuild of Go packages after 1.21 lands in rawhide?

Both approaches should be fine, but I think a releng-managed side tag will be needed for the second approach.

that said, +1

It seems like I missed this announcement on the devel list ... the proposal says it will require a mass rebuild of all Go packages (obviously), but that golang 1.21 will only be released in August, while the Fedora 39 mass rebuild will happen in two weeks (starting July 19, at least according to the schedule). Does this mean we will have a golang 1.21 beta / pre-release in time for the f39 mass rebuild, or will there be a targeted mass rebuild of Go packages after 1.21 lands in rawhide?

Both approaches should be fine, but I think a releng-managed side tag will be needed for the second approach.

that said, +1

Probably (like most of the previous releases) it will be with a rc. In this case, I have the latest rc ready in a pull request:
https://src.fedoraproject.org/rpms/golang/pull-request/79

As a side note, we can consider (it's something that has been discussed recently) do a mid release mass rebuild to force the rebuild on some packages due to CVEs that the minor releases will fix.

Both approaches should be fine, but I think a releng-managed side tag will be needed for the second approach.

We should not need a releng managed side tag. Only these packages would need to be rebuilt. There's no need to rebuild the packages that only provide noarch -devel subpackages. We've done rebuilds of this magnitude through Bodhi in the normal fashion multiple times already.

That's true, but I assumed you'd want all go packages' (also libraries) test suites to be run during the mass rebuild.

The ticket is 1 week old now, so:

Approved(+5, 0, 0)

Metadata Update from @tstellar:
- Issue tagged with: pending announcement

2 years ago

Metadata Update from @zbyszek:
- Issue untagged with: pending announcement
- Issue close_status updated to: Accepted
- Issue status updated to: Closed (was: Open)

2 years ago

Log in to comment on this ticket.

Metadata