Go 1.25 in Fedora 42 #3570

Closed
opened 2026-02-17 08:22:59 +00:00 by alexsaezm · 25 comments

Fedora 42 has Go 1.24, which is effectively EOL since 1.26.0 came out recently.

As in previous requests, can we update the version in Fedora 42 to Go 1.25 to avoid the EOL and allow packages to be updated?.

Previously, it was suggested to make this part of the usual release process for newer versions of Go, but I don't recall adding it to the 1.26 proposal, so I open this ticket once more for transparency.

Fedora 42 has Go 1.24, which is effectively EOL since 1.26.0 came out recently. [As in previous requests](https://pagure.io/fesco/issue/3435), can we update the version in Fedora 42 to Go 1.25 to avoid the EOL and allow packages to be updated?. Previously, it was suggested to make this part of the usual release process for newer versions of Go, but I don't recall adding it to the 1.26 proposal, so I open this ticket once more for transparency.
Owner

+1

+1
Owner

Metadata Update from @decathorpe:

  • Issue tagged with: updates policy exception
**Metadata Update from @decathorpe**: - Issue tagged with: updates policy exception
Owner

+1, but also:

Proposal: Given that the Go schedule is predictable and not aligned with Fedora's stable lifecycle, FESCo grants a blanket permission to update stable Fedora releases to newer Go releases.

+1, but also: Proposal: Given that the Go schedule is predictable and not aligned with Fedora's stable lifecycle, FESCo grants a blanket permission to update stable Fedora releases to newer Go releases.
Owner

Yeah, +1 this request, but also +1 a persistent approval.

Yeah, +1 this request, but also +1 a persistent approval.
Owner

Yes to the permanent exception. +1

Yes to the permanent exception. +1
Owner

+1, with the caveat that for now, I'd only think this should happen on Fedora N-1 as soon as the Go version there is EOL upstream. A permanent blanket exception for stable branches is something that could be considered, but that would require more discussion IMO.

+1, with the caveat that for now, I'd only think this should happen on Fedora N-1 as soon as the Go version there is EOL upstream. A permanent blanket exception for stable branches is something that could be considered, but that would require more discussion IMO.
Owner

+1 to both too. (Though I agree with decathorpe that it'd be better to do this separately, with a concrete proposal text.)

+1 to both too. (Though I agree with decathorpe that it'd be better to do this separately, with a concrete proposal text.)
Author

+1, with the caveat that for now, I'd only think this should happen on Fedora N-1 as soon as the Go version there is EOL upstream. A permanent blanket exception for stable branches is something that could be considered, but that would require more discussion IMO.

Absolutely, when I said, "make this part of the usual release process", I meant to do it only on Fedora N-1 and only when the Go version goes EOL. I do believe it is the sane and conservative way to handle the schedule mismatch.

> +1, with the caveat that for now, I'd only think this should happen on Fedora N-1 as soon as the Go version there is EOL upstream. A permanent blanket exception for stable branches is something that could be considered, but that would require more discussion IMO. Absolutely, when I said, "make this part of the usual release process", I meant to do it only on Fedora N-1 and only when the Go version goes EOL. I do believe it is the sane and conservative way to handle the schedule mismatch.
Owner

OK, I'll revise my previous Proposal to be more constrained.

Proposal: Given that the Go schedule is predictable and not aligned with Fedora's stable lifecycle, FESCo grants a blanket permission to update stable Fedora releases to the next supported release once the version that was shipped at Fedora's GA has gone end-of-life.

Note: this restarts the seven-day voting period for the permanent exception, but the original request on this ticket will be approved tomorrow, assuming no -1 votes appear.

OK, I'll revise my previous Proposal to be more constrained. Proposal: Given that the Go schedule is predictable and not aligned with Fedora's stable lifecycle, FESCo grants a blanket permission to update stable Fedora releases to the next supported release once the version that was shipped at Fedora's GA has gone end-of-life. Note: this restarts the seven-day voting period for the permanent exception, but the original request on this ticket will be approved tomorrow, assuming no -1 votes appear.
Owner

+1 for the specific exception

Also +1 for the blanket permission in stable releases if the golang version shipped goes EOL per Stephen's last proposal

+1 for the specific exception Also +1 for the blanket permission in stable releases if the golang version shipped goes EOL per Stephen's last proposal
Owner

+1 to the revised proposal.

+1 to the revised proposal.
Owner

+1 to revised proposal.

+1 to revised proposal.
Owner

+1 to revised proposal.

+1 to revised proposal.
Owner

+1 to revised proposal and pre-emptively approving permanent exception.

+1 to revised proposal and pre-emptively approving permanent exception.
Owner

The first part is approved after a week:
APPROVED (+5, 0, 0): "update the version in Fedora 42 to Go 1.25 to avoid the EOL and allow packages to be updated"

The first part is approved after a week: APPROVED (+5, 0, 0): "update the version in Fedora 42 to Go 1.25 to avoid the EOL and allow packages to be updated"
Owner

Metadata Update from @zbyszek:

  • Issue tagged with: pending announcement
**Metadata Update from @zbyszek**: - Issue tagged with: pending announcement
Owner

I filed fesco/docs#128 based on @sgallagh's proposal.

I filed https://forge.fedoraproject.org/fesco/docs/pulls/128 based on @sgallagh's proposal.
Owner

The PR was merged.

The PR was merged.
Owner

Announced in the 2026-02-24 meeting summary

Announced in the 2026-02-24 meeting summary
Owner

Metadata Update from @sgallagh:

  • Issue close_status updated to: Accepted
  • Issue status updated to: Closed (was: Open)
**Metadata Update from @sgallagh**: - Issue close_status updated to: Accepted - Issue status updated to: Closed (was: Open)
Owner

Reopening while we resolve the question of a permanent exception. It was probably premature to merge the docs MR yet, but in the unlikely event that we reject this proposal, we can revert it.

Reopening while we resolve the question of a permanent exception. It was probably premature to merge the docs MR yet, but in the unlikely event that we reject this proposal, we can revert it.
Owner

Metadata Update from @sgallagh:

  • Issue status updated to: Open (was: Closed)
**Metadata Update from @sgallagh**: - Issue status updated to: Open (was: Closed)
Owner

Reopening while we resolve the question of a permanent exception. It was probably premature to merge the docs MR yet, but in the unlikely event that we reject this proposal, we can revert it.

Oh indeed, I shouldn't have done that. But let's just wait for the clock to run out.

> Reopening while we resolve the question of a permanent exception. It was probably premature to merge the docs MR yet, but in the unlikely event that we reject this proposal, we can revert it. Oh indeed, I shouldn't have done that. But let's just wait for the clock to run out.
Owner

I think both parts (the one-time exception and the permanent exception) can be considered approved now. It's been enough time and there haven't been negative votes.

I think both parts (the one-time exception and the permanent exception) can be considered approved now. It's been enough time and there haven't been negative votes.
Owner

Metadata Update from @decathorpe:

  • Issue untagged with: pending announcement
  • Issue close_status updated to: Accepted
  • Issue status updated to: Closed (was: Open)
**Metadata Update from @decathorpe**: - Issue **un**tagged with: pending announcement - Issue close_status updated to: Accepted - Issue status updated to: Closed (was: Open)
Sign in to join this conversation.
No milestone
No project
No assignees
8 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
fesco/tickets#3570
No description provided.