- Refer to link:https://fedoraproject.org/wiki/Fedora_Release_Life_Cycle[Fedora Release Life Cycle] for more details.

- It must not be in list of https://fedoraproject.org/wiki/Forbidden_items[Forbidden Items].

- This policy is for applications that set or change passphrases/passwords locally on Fedora installations. One central place for policy for passphrases was desired and that is now in the `libpwquality` package. This package ships defaults for Fedora as decided by FESCo. Fedora products can override the defaults by creating their own `/etc/security/pwquality.conf.d/` configuration file. The local administrators can set their own policy in the master `/etc/security/pwquality.conf` file.

- This policy is only for applications that set or change local passwords/passphrases. It has nothing to do with remote/central authentication stores, which can and do still have their own policies.

- * root / admin users should be able to override quality checks (for purposes of this, the installing user is root/admin)

- * applications may use the `libpwquality` 'score' to display an analog strength meter to users as an informational tool, but should not use score as a decision making factor for acceptance.

- link:https://fedoraproject.org/wiki/Legal:Main[Fedora Legal] guidelines and

- link:https://docs.fedoraproject.org/en-US/project/code-of-conduct/index.html[Code of Conduct].

- Addition of new Spins follows the standard link:https://docs.fedoraproject.org/en-US/program_management/changes_policy/[Change process].

- link:https://docs.fedoraproject.org/en-US/program_management/changes_policy/#_system_wide_changes[System-wide Change],

- Fedora has differing policies for each of its branches. This document describes for maintainers what

- sort of updates should be created in packages for each of the various branches of existing Fedora.

- In the event of questions or clarifications, please file a

- link:https://pagure.io/fesco/new_issue[FESCo ticket] or discuss on the

- link:https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/[devel list]. In

- general, releases should go from less conservative (Rawhide) to more so (the oldest supported stable

- release). This document attempts to describe when and what kinds of updates maintainers should push

- to Fedora users of its various branches. The

- link:https://fedoraproject.org/wiki/Stable_release_updates_vision#Vision_Statement[Stable release updates vision] from the

- Fedora Board includes more high level discussion and philosophy, while this

- document is more a practical guide. Refer to

- link:https://docs.fedoraproject.org/en-US/package-maintainers/Package_Update_Guide[Package Update Guide] for the technical steps on

- pushing the updates. The link:https://fedoraproject.org/wiki/Fedora_Release_Life_Cycle[Fedora Release Life Cycle]

- provides a more detailed overview of the development process.

- When one updated package requires one or more other packages, the packages should be submitted

- together as a single update. For instance, if package A depends on packages B and C, and you want to

- update to a new version of package A which requires new versions of B and C, you must submit a

- single update containing the updated versions of all three packages. It is a bad idea to submit

- three separate updates, because if the update for package A is pushed stable before the updates for

- packages B and C, it will cause dependency problems. There is information on how to submit

- multi-package updates in the

- link:https://docs.fedoraproject.org/en-US/package-maintainers/Package_Update_Guide/#updating_inter_dependent_packages[Package Update Guide]

- link:https://docs.fedoraproject.org/en-US/rawhide-gating/multi-builds/[Rawhide Gating/multi-builds].

- link:https://bodhi.fedoraproject.org[Bodhi]

- This sort of testing should be done in link:https://copr.fedorainfracloud.org/[Copr] or other

- seperate public repositories. Consult with the QA team for further testing assistance.

- link:https://fedoraproject.org/wiki/Releases/Rawhide[Rawhide] is the always-rolling development tree.  Package

- updates built for Rawhide are composed every day and pushed out to all consumers.

- New builds against this tree also are added to the build root (i.e., other packages build from them).

- This tree is intended to meet the link:https://fedoraproject.org/wiki/Basic_Release_Criteria[Basic Release Critera]

- for any successfull compose so maintainers can integrate their changes with everyone else.

- 

- Repos available: link:https://fedoraproject.org/wiki/Repositories#rawhide[_rawhide_]

- 

- Since link:https://fedoraproject.org/wiki/Changes/GatingRawhidePackages[Gating Rawhide Packages] change was introduced,

- package updates in Fedora Rawhide need to pass verification before they land in the Rawhide repositories. This

- is implemented as a check for the Bodhi update, which verifies that the update satisfies the Gating policy. See

- link:https://docs.fedoraproject.org/en-US/rawhide-gating/single-builds/[Rawhide Gating/Single Builds] and

- link:https://docs.fedoraproject.org/en-US/rawhide-gating/multi-builds/[Rawhide Gating/Multi Builds] for

- details.

- 

- Currently the default gating policy is empty, thus a Rawhide update can pass the gate, no matter the test

- results. Package maintainer can opt-in for the gating of a package, by setting up individual gating policies,

- see link:https://docs.fedoraproject.org/en-US/rawhide-gating/optin/[How to Opt in to Gating].

-   link:https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/[devel list]

-   link:https://docs.fedoraproject.org/en-US/rawhide-gating/multi-builds/[Rawhide Gating/Multi Builds].

- * Feel free to push out the newest version of packages as long as they do not cause breakage. Also

-   keep in mind when the next Fedora release will be branched off, and be fairly confident that there

-   will be a stable enough release in time for the next Fedora release. Otherwise you may have to

-   back down to an older, stable version after the branching, which may involve epochs and other

-   inconveniences.

- * Once a package has been added to the compose and that compose has finished and synced to the master

-   mirrors, it will normally not be untagged. This is required to allow others to depend on the

-   build once it has become visible. In exceptional cases, releng may untag packages.

-   The benefits of the early real-world testing of and upstream collaboration on these key

-   packages far exceeds the risks that they may introduce.

- A link:https://fedoraproject.org/wiki/Releases/Branched[Branched] release exists for part of the

- development cycle. It starts as a fork of Rawhide and eventually becomes the next stable release.

- link:https://fedoraproject.org/wiki/Basic_Release_Criteria[Basic Release Critera].

- Branched releases use the update feedback system (link:https://bodhi.fedoraproject.org[Bodhi]): at first just like Rawhide (updates are

- automatically created when a build finishes, tests run and builds are automatically pushed into the next

- compose), but then after <<updates-testing-activation>> they switch to using it as stable releases do

- There are several phases that a branched release goes through that affect what updates can and

- should be done. In general maintainers should keep in mind that this tree is being stabilized

- for the next release, so changes should be careful and considered and heading toward stability.

- Once the new release is branched off Rawhide, the flow of updates through Bodhi is stopped until

- there has been a successful branched compose. This period usually lasts just a few days. Release

- engineering may pass some updates to stable to get the compose to complete, but otherwise all updates

- are paused until this initial branched compose is completed. This is to make sure we have a

- compose to build on and aren't dealing with problems landing in new updates before we are

- ready for them.

- builds submitted by packagers are considered

- _stable_ after passing through any gating tests

- via a Bodhi update, and are sent to the

- link:https://fedoraproject.org/wiki/Repositories#fedora[_fedora_] repository directly in the next nightly

- compose. There are no restrictions beyond those for Rawhide at this point, but maintainers SHOULD be

- thinking about stabilization from this point onward, and making sure their packages will be in good

- condition well in advance of the stable release.

- Repos available: link:https://fedoraproject.org/wiki/Repositories#fedora[_fedora_]

- and updates pass through link:https://fedoraproject.org/wiki/QA:Updates_Testing[_updates-testing_]

- Updates are moved from link:https://fedoraproject.org/wiki/Repositories#updates-testing[_updates-testing_]

- repository to link:https://fedoraproject.org/wiki/Repositories#fedora[_fedora_]

- Repositories available: link:https://fedoraproject.org/wiki/Repositories#fedora[_fedora_],

- link:https://fedoraproject.org/wiki/Repositories#updates-testing[_updates-testing_]

- * Avoid ABI/API changes where possible. If unavoidable, use a side-tag to rebuild packages.

- link:https://fedoraproject.org/wiki/Repositories#updates-testing[_updates-testing_] to

- link:https://fedoraproject.org/wiki/Repositories#fedora[_fedora_]

- link:https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process[blocker bug process] or

- link:https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process[freeze exception bug process].

- The link:https://fedoraproject.org/wiki/Milestone_freezes[Milestone freezes]

- Once the Beta Freeze starts, we are

- attempting to stabilize the major versions of software that will be shipped with the final release

- of the OS. Major updates can be tolerated, but breaking things for early testers should be avoided

- if possible.

-   link:https://fedoraproject.org/wiki/Repositories#updates-testing[_updates-testing_].

- Repositories available: link:https://fedoraproject.org/wiki/Repositories#fedora[_fedora_],

- link:https://fedoraproject.org/wiki/Repositories#updates-testing[_updates-testing_]

- Repositories available: link:https://fedoraproject.org/wiki/Repositories#fedora[_fedora_],

- link:https://fedoraproject.org/wiki/Repositories#updates-testing[_updates-testing_]

- Repositories available: link:https://fedoraproject.org/wiki/Repositories#fedora[_fedora_],

- link:https://fedoraproject.org/wiki/Repositories#updates[_updates_],

- link:https://fedoraproject.org/wiki/Repositories#updates-testing[_updates-testing_]

-   repository is available, builds marked as _stable_

-   will go there instead of to

-   link:https://fedoraproject.org/wiki/Repositories#fedora[_fedora_].

- Releases of the Fedora distribution are like releases of the individual packages that compose it. A

- major version number reflects a more-or-less stable set of features and functionality. As a result,

- we should avoid major updates of packages within a stable release. Updates should aim to fix bugs,

- and not introduce features, particularly when those features would materially affect the user or

- developer experience. The update rate for any given release should drop off over time, approaching

- zero near release end-of-life; since updates are primarily bugfixes, fewer and fewer should be

- needed over time.

- 

- This necessarily means that stable releases will not closely track the very latest upstream code for

- all packages. We have Rawhide for that.

- 

- Updates should be carefully considered with respect to their dependencies. An update that required

- (or provided) a new Python ABI, for example, would almost certainly not be allowed. ABI changes in

- general are very strongly discouraged, they force larger update sets on users and they make life

- difficult for third-party packagers. Additionally, updates that convert resources or configuration

- one way (i.e., from older->newer) should be approached with extreme caution as there would be much

- less chance of backing out an update that did these things.

- 

- Whenever possible packagers should work with upstream to come up with stable branch releases or

- common patches for older releases, particularly when updating would require large dependency chain

- updates.

- 

- Repositories available: link:https://fedoraproject.org/wiki/Repositories#fedora[_fedora_],

- https://fedoraproject.org/wiki/Repositories#updates[_updates_],

- link:https://fedoraproject.org/wiki/Repositories#updates-testing[_updates-testing_]

-   link:https://fedoraproject.org/wiki/Repositories#updates-testing[_updates-testing_].

-   link:https://fedoraproject.org/wiki/Repositories#updates[_updates_] repository.

- Some classes of software will not fit in these guidelines. If your package does not fit in one of

- the classes below, but you think it should be allowed to update more rapidly, propose a new

- exception class to FESCo and/or request an exception for your specific update case.

- * Additionally, multiple kernels can be installed/booted, allowing users to boot older kernels in

-   the event newer ones fail to work, and allowing time for kernel maintainers to fix any critical

-   bugs in new kernels on older stable releases.

- Refer to the link:https://fedoraproject.org/wiki/SIGs/KDE/Update_policy[KDE update policy] for more

- details

- * the document viewer `zathura` and the `girara` library (link:https://pagure.io/fesco/issue/1255[FESCo #1255]),

-   (link:https://pagure.io/fesco/issue/2652[FESCo #2652]),

-   (link:https://pagure.io/fesco/issue/2652[FESCo #2652]),

-   (link:https://pagure.io/fesco/issue/2652[FESCo #2652]),

-   (link:https://pagure.io/fesco/issue/2652[FESCo #2652]),

-   (link:https://pagure.io/fesco/issue/2652[FESCo #2652]).

-   (link:https://pagure.io/fesco/issue/2762[FESCo #2762]).

-   (link:https://pagure.io/fesco/issue/3115[FESCo #3115]).

-   (link:https://pagure.io/fesco/issue/3124[FESCo #3124]).

- FESCo will review the ticket in a timely manner and give guidance as to how the package

- maintainer(s) should proceed. By way of information, several common items that would make it less

- likely for FESCo to grant a rebase request are listed below. Please note, however, that this list is

- not exhaustive.

- 

- FESCo will be less likely to grant a rebase request if:

- * The update causes policy or behavior changes (such as when something that was previously denied is

-   now allowed, etc.)

- * The update changes the way the end user interacts with the user interface (such as moving menus or

-   buttons to a new location, changing names of command-line arguments, etc.)

- * The rebase only addresses issues that are likely to affect a subjectively small number of Fedora

-   users

- If a package primarily serves to interoperate with hardware or network protocols, and the interface

- changes, then a package may be rebased if necessary. This includes network games, IM protocols,

- hardware music players, cell phones, etc. These packages may also be updated to add support for new

- devices or formats in compatible ways.

- link:https://src.fedoraproject.org/rpms/libopenraw[``libopenraw``],

- link:https://src.fedoraproject.org/rpms/libimobiledevice[``libimobiledevice``],

- link:https://src.fedoraproject.org/rpms/calibre[``calibre``],

- link:https://src.fedoraproject.org/rpms/pilot-link[``pilot-link``]

- Packages like virus scanners and spam filters typically have two components: a rules engine and a

- database. The database is expected to update frequently (sometimes not through the normal OS update

- mechanisms), but the rules engine is usually fairly static. However, if the maintained database

- changes to require a new version of the rules engine, then the package may be a candidate for

- rebasing.

- link:https://src.fedoraproject.org/rpms/spamassassin[``spamassassin``],

- link:https://src.fedoraproject.org/rpms/clamav[``clamav``]

- * Mozilla releases Firefox 4.0.1 with a security fix. Fedora 12 is shipping with 3.0.7, and though

-   the bug is also present there, the fix in 4.0.1 does not apply because that part of the browser

-   has been completely rewritten. Rebasing to 4.0.1 would be allowed since this is a security fix.

- * automake releases a new version that changes some warning conditions to errors. This would break

-   the build process for existing packages, and would not be allowed.

- * AOL changes their instant messenger protocol in a way that requires an update to libpurple. The

-   only upstream version of libpurple that supports the new protocol is an ABI break relative to the

-   version in the current Fedora release. Rebasing would be allowed since this is an interoperability

-   requirement.

- * Abiword releases a new version that adds compatibility with WordStar 4.0 documents. It also

-   completely updates the user interface to use pie menus. This would be a feature enhancement with a

-   major user experience change, and would not be allowed.

- * WebKit requires an update to solve a security problem. This requires updating Midori to a version

-   with some minor menu layout changes. This would be a judgment call based on how intrusive the

-   changes are (removing the File menu would be rude, but moving the plugin configuration menu item

-   would be acceptable).

-   but should not be pushed to stable releases, as it does no good to our users

-   ability to not update other parts of Fedora for this update (i.e., avoid Qt or other base library ABI changes),

- from link:https://fedoraproject.org/wiki/Repositories#updates-testing[_updates-testing_]

- to link:https://fedoraproject.org/wiki/Repositories#fedora[_fedora_]

- link:https://fedoraproject.org/wiki/Bodhi[Bodhi] karma points

- * The update becomes **eligible for being pushed manually** after reaching the _minimum_ "Stable by Karma" threshold

-   for Critical path updates (yes, the same limit applies to both types of updates),

- * The update will be **pushed automatically** by Bodhi after reaching the _configured_ "Stable by Karma" threshold,

-   OR the _configured_ "Stable by Time" threshold,

-   if enabled ("Auto-request stable based on karma?" and "Auto-request stable based on time?").

- The maintainer is free to set the thresholds, but they cannot be lower than the minimum values described below,

- The defaults are adequate for most packages, so usually there is no need to modify the thresholds.

- Stable by Karma: minimum +1, default +3, between <<updates-testing-activation>> and <<beta-freeze>> +

-                        minimum +2, default +3, after <<beta-freeze>> +

- Unstable by Karma: maximum -1, default -3 +

- Stable by Time (days): minimum 3, default 3, between <<updates-testing-activation>> and <<beta-freeze>> +

-                        minimum 7, default 7, after <<beta-freeze>>

- link:https://fedoraproject.org/wiki/Critical_path_package[critical path package]. +

- Stable by Karma: minimum +1, default +3, between <<updates-testing-activation>> and <<beta-freeze>> +

-                        minimum +2, default +3, after <<beta-freeze>> +

- Unstable by Karma: maximum -1, default -3 +

- Stable by Time (days): minimum 3, default 3, between <<updates-testing-activation>> and <<beta-freeze>> +

-                        minimum 14, default 14, after <<beta-freeze>>

- In an effort to learn from any mistakes made, in the event of a update causing a widespread or

- serious problem for Fedora users, please file a link:https://pagure.io/fesco/new_issue[FESCo ticket]. FESCo will discuss and try and

- work to prevent the issue from happening again. A past record of such issues can be found at

- link:https://fedoraproject.org/wiki/Updates_Lessons[Updates Lessons].

- link:https://openqa.fedoraproject.org[OpenQA] tests critpath updates in stable releases and compose artifacts

- link:https://docs.fedoraproject.org/en-US/ci/[Fedora CI] runs tests on all Bodhi updates. If package

- maintainers have marked the tests as blocking, the Bodhi update will be blocked

- from going stable.