+1

+1

I know that this is necessary to continue receiving security updates for important packages like docker and kubernetes, as most Go projects only support two Go versions at once but https://lists.fedoraproject.org/archives/list/golang@lists.fedoraproject.org/thread/AQRBENDKBYJLGX5DKQTSLNOI6W4HIHT3/ might be a problem. I wonder if a compat package would be a better choice.

I know that this is necessary to continue receiving security updates for important packages like docker and kubernetes, as most Go projects only support two Go versions at once but https://lists.fedoraproject.org/archives/list/golang@lists.fedoraproject.org/thread/AQRBENDKBYJLGX5DKQTSLNOI6W4HIHT3/ might be a problem. I wonder if a compat package would be a better choice.

You are 100% right. I'm not sure how a compat package works. I searched a little bit on the repositories and I saw several -compat- packages as different repositories. But I don't see any documentation. Do you have a good example for this? I feel that is worth checking and maybe even adding it as an additional step to future Fedora branches.

if you wanted to make a compat package for go 1.24 instead, it would be named "golang1.24" (with the "1.24" suffix being applied to all subpackages too, probably).

However, I don't think this would actually work? How would I tell the %gometa macro to pull in (and cause %gobuild to use!) a different golang version?

I guess a way out to this would be to grant an exception as well to rebase affected F41 packages to their F42 versions if we have to rebuild them (e.g. if a security issue is discovered)?

+1 for the exception requested as well, and implicitly +1 to also preemptively allow what I described above

Sounds good.

+1 on salimma's proposal.

More generally, I wonder if we should formalize this exception also for future Fedora/Go versions, considering that this timing issue happens at every cycle

+1 on salimma's proposal.

More generally, I wonder if we should formalize this exception also for future Fedora/Go versions, considering that this timing issue happens at every cycle

Can it be part of a next Fedora release proposal? As you said, this happens at every cycle, and the approval of the next Go release proposal is usually the milestone I use to open these tickets.

But it might be confusing to have two Fedora releases in the same proposal.

I think it's fine to have the next release proposal talk about how existing releases will be brought up to date - IIRC we did this in the Django proposal

Not sure how to count these votes - if I tally all the +1s we are at +4, if we count my slightly edited proposal I think it's +3 since @zbyszek is OK with it but @decathorpe hasn't responded

So I think this is either +3 or +4 ... let's just err on caution

APPROVED (3, 0, 0)

Announced: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/LWF6PRIEWI4GW6WFQRMJ2A3PZZNIS2YF/