Re: Should the policy documents better reflect real package maintenance practice?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

_______________________________________________
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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux