As a practical example, if
Fedora prefers stability for application packages over early
updates, I'd like to use Thunderbird as an example because the
upstream vendor supports two releases concurrently for a
predictable period of ~ 12 weeks.
In practice, maintaining that
package might look like this:
Thunderbird update policy:
Thunderbird releases follow the Mozilla ESR calendar [1] relatively closely. Each stable release series is supported for a little over a year, and each release lifecycle overlaps with the subsequent release for at least 12 weeks to allow users a transition period that provides time to test and adapt to breaking API changes.
For Fedora releases, Thunderbird should rebase to a new stable release in Rawhide as early as possible, while stable Fedora releases should remain on the old stable series for as long as possible.
Firefox ESR releases occur every four weeks (five in some cases), on Tuesday, and Thunderbird will release shortly thereafter. The release cadence makes package maintenance fairly predictable.
Roughly every four weeks, the newest release [2] should be built in Rawhide, and in any branched but not yet final Fedora release.
If that release is a new release series, a self-contained change announcement should be added to the upcoming Fedora release proposals, possibly referring to the changes documented in the webextension API guide [3].
If there was also a release from the previous release series, that release should also be built in each active Fedora release. However, if there was no release from a prior release series, then the newest release should also be built in each active Fedora release.
1: https://wiki.mozilla.org/Release_Management/Calendar
2: https://www.thunderbird.net/en-US/thunderbird/releases/
3: https://webextension-api.thunderbird.net/en/latest/index.html
Thunderbird releases follow the Mozilla ESR calendar [1] relatively closely. Each stable release series is supported for a little over a year, and each release lifecycle overlaps with the subsequent release for at least 12 weeks to allow users a transition period that provides time to test and adapt to breaking API changes.
For Fedora releases, Thunderbird should rebase to a new stable release in Rawhide as early as possible, while stable Fedora releases should remain on the old stable series for as long as possible.
Firefox ESR releases occur every four weeks (five in some cases), on Tuesday, and Thunderbird will release shortly thereafter. The release cadence makes package maintenance fairly predictable.
Roughly every four weeks, the newest release [2] should be built in Rawhide, and in any branched but not yet final Fedora release.
If that release is a new release series, a self-contained change announcement should be added to the upcoming Fedora release proposals, possibly referring to the changes documented in the webextension API guide [3].
If there was also a release from the previous release series, that release should also be built in each active Fedora release. However, if there was no release from a prior release series, then the newest release should also be built in each active Fedora release.
1: https://wiki.mozilla.org/Release_Management/Calendar
2: https://www.thunderbird.net/en-US/thunderbird/releases/
3: https://webextension-api.thunderbird.net/en/latest/index.html
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
