I spoke with Aoife, she will update the Fedora Schedule to match, but for future:

Where does the EOL date in fedora-release.spec originate from and how to keep it in sync between os-release, Bodhi, and Schedule, @sgallagh?

The EOL date has been set to match the one in `fedora-release.spec`, i.e. 2025-12-02, in Fedora Schedule, no need to update anything in the spec file.

The F43 schedule is now updated to match the date in the spec file https://fedorapeople.org/groups/schedule/f-43/f-43-key-tasks.html

For future schedules, if I know the milestone or date the spec file EOL date is generated from, I can add a little formula in each future schedules to continue to keep them in sync. From looking at F43, it seems that the spec file takes the date from the Target Date #3. If this is correct, and/or also makes sense to use as a 'rule' going forward, Im happy to update all schedule EOL dates against this date and update the schedule SOP in the pgm docs too so we are kept in sync.

(In reply to Lukas Ruzicka from comment #1)
> I spoke with Aoife, she will update the Fedora Schedule to match, but for
> future:
> 
> Where does the EOL date in fedora-release.spec originate from and how to
> keep it in sync between os-release, Bodhi, and Schedule,
> @sgallagh?

(In reply to Aoife Moloney from comment #3)
> The F43 schedule is now updated to match the date in the spec file
> https://fedorapeople.org/groups/schedule/f-43/f-43-key-tasks.html
> 
> For future schedules, if I know the milestone or date the spec file EOL date
> is generated from, I can add a little formula in each future schedules to
> continue to keep them in sync. From looking at F43, it seems that the spec
> file takes the date from the Target Date #3. If this is correct, and/or also
> makes sense to use as a 'rule' going forward, Im happy to update all
> schedule EOL dates against this date and update the schedule SOP in the pgm
> docs too so we are kept in sync.


I think you've got it backwards here, Aoife. This value in the spec file is meant to be derived from the official Fedora schedule, not the reverse. There's no sensible way to automate this, so it has to be manually set for each release. As I understand it, @awilliam set up an OpenQA test in https://pagure.io/fedora-qa/os-autoinst-distri-fedora/issue/347 that is supposed to result in a ticket like this one being filed whenever /etc/release is either not at least 12 months later than the release date or it doesn't agree with both the schedule and the Bodhi configuration.

The EOL date should match the "EOL auto closure" date for Fedora N+2, which for F43/F45 is still listed as 2026-11-18 at https://fedorapeople.org/groups/schedule/f-45/f-45-all-tasks.html

Exactly, this is why I have reported this bug.

As soon as we agree about which date is correct, I'll go ahead and update the RPM spec file accordingly.

Oh I see. Thats actually not too bad, I think I can fix this with a bit of schedule review and realignment anyway. I will probably have to take a specific release date as the milestone to anchor the EOL date from through all releases, so if theres no objection I can formally make it 'target date 3' as the date the EOL date is always used against. That should give us consistency throughout the schedules. It may mean some releases are maintained longer than others if some release on the early target date, but this shouldnt be any mroe than ~3 weeks. Should I file a FESCo ticket notifying them of this scheduling rule?

@sgallagh please take the 2026/12/02 date as the correct EOL date for F43 on the presumption we use the target date 3 as the milestone date from now on for this. Ill make sure thats reflected in the F45 schedule too.

If I remember from previous conversations:

* The release is meant to be supported for four weeks after the GA release of Fedora N+2, *whenever that happens*.[1]
* The EOL date in the os-release file is allowed to be extended after release, but it may not be shortened. So our best bet is to just set the EOL date at 13 months after the earliest release date in the schedule and we can optionally extend it out as a post-release update to the fedora-release package.
* It's possible for us to slip the release past any of the scheduled targets if circumstances require it.

So, the safest move is for the EOL date in /usr/lib/os-release to be set as 13 months from Target Date #1 and then we can modify it to be later once we know our real ship date.

I propose that we add the following process:

0. The Fedora Schedule always contains at least Fedora N-2 through Fedora N+2 schedule dates. The EOL date of Fedora N when created is set at Target Date #1 plus four weeks. 
1. The Branching SOP is extended to include setting /usr/lib/os-release to include the EOL date for the new Rawhide fedora-release package as Fedora N+1 as described above. (Branched should already have been set appropriately from when it was Rawhide)
2. When the decision is "GO!" at the Go/No-Go meeting, the following tickets are filed if the EOL date has been extended out due to delays in release of Fedora N.:
  2a. against the Fedora Schedule to ensure that true date is recorded in the official record.
  2b. against fedora-release to ensure that an update for fedora-release of the *Fedora N-2* is released and includes the finalized EOL date.
  2c. against Bodhi to ensure that the EOL date matches the schedule.

Put another way: we start by setting it to the earliest possible date and let people be pleasantly surprised if it gets a slight reprieve near the end.


[1] Old-timers will remember that Fedora 19 and 20 were supported for 18 months because Fedora 21 was significantly delayed by the Fedora.Next changes.

(In reply to Stephen Gallagher from comment #8)

> Put another way: we start by setting it to the earliest possible date and
> let people be pleasantly surprised if it gets a slight reprieve near the end.

Sounds good to me, thanks.

That's +1 for me too. I will write this down now as well in the PgM guide so theres some kind of record on what the EOL date is based from and the procedure for delays for future me and not-me's to come :)

Sounds reasonable.

Ive updated the F45 schedule to match the EOL date for F43 so they are the same across both. I have not done the updates to the SOP for PgM yet, so please dont close this bug, feel free to reassign it to me if I am the only one left with action items for this and Ill finish it out on Tuesday 7 Oct when I am back in the office.

There is a discrepancy again, Bodhi and os-release show 2026-12-02 as EOL, Fedora Schedule shows 2026-12-09.
Please, fix.

Hum, so I don't think the way we are doing this is ideal. 

The current/above way means that if we miss the 'early' date, we move the eol date again, if we miss the next target, we move it again, etc. 
Thats a lot of churn and moving of things. 

Why don't we just set the eol date out so we can at least miss early and first target before we need to adjust it again? ie, set it now for 2025-12-16 ? 

Just a thought to try and avoid churn.

Ok what Ive done in the schedule is set the EOL date of that release to be dependant on the 'current' date for Final. That 'current date' entry anchors all other dates, so if we miss an early, or target 1, 2, etc, someone needs only to change the 'Current' date for Final and the EOL date will update automatically. And rebuild the schedule. A PR or issue still needs to be filed though in Bodhi and os-release though when/if the release date slips as that moves the EOL date.

Thats actually in the PgM guide so I apologise, that was something I should have done but didnt. Ill ask Jef to be aware of that process for F44 in case the EOL date changes as a consequence of a missed target.

I do like Kevins idea to standardize on a set time for EOL, but Im out of time to see what happens. In the meantime, Ive tried to tighten the schedule smartsheet as much as possible.

Still inconsistent ATM, as per #c13.