No edit summary |
(more stuff) |
||
| (2 intermediate revisions by the same user not shown) | |||
| Line 3: | Line 3: | ||
== Philosophy == | == Philosophy == | ||
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 | 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. | ||
Rebases should be carefully considered with respect to their dependencies. A rebase that required (or provided) a new Python ABI, for example, would almost certainly not be allowed. Whenever possible packagers should work with upstream to come up with stable branch releases or common patches for older releases, particularly when rebasing would require large dependency chain updates. | This necessarily means that stable releases will not closely track the very latest upstream code for all packages. We have rawhide for that. | ||
Rebases should be carefully considered with respect to their dependencies. A rebase 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. | |||
Whenever possible packagers should work with upstream to come up with stable branch releases or common patches for older releases, particularly when rebasing would require large dependency chain updates. | |||
== Exceptions == | == Exceptions == | ||
| Line 17: | Line 21: | ||
=== Interoperability === | === Interoperability === | ||
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. | 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. | ||
Examples of this type of package: libopenraw, libimobiledevice, calibre, pilot-link | |||
=== Database packages === | === Database packages === | ||
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. | 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. | ||
Examples of this type of package: spamassassin, clamav | |||
== Examples == | == Examples == | ||
| Line 32: | Line 40: | ||
* 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. | * 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 judgement 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). | |||
== History == | |||
This section is currently a placeholder, but should be used to record examples of actual update scenarios that have been allowed or forbidden for interesting reasons. Those who do not learn from history... | |||
Latest revision as of 18:08, 31 August 2010
Don't take me seriously yet, I'm still under review.
Philosophy
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.
Rebases should be carefully considered with respect to their dependencies. A rebase 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.
Whenever possible packagers should work with upstream to come up with stable branch releases or common patches for older releases, particularly when rebasing would require large dependency chain updates.
Exceptions
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.
Security fixes
If upstream does not provide security fixes for a particular release, and if backporting the fix would be impractical, then a package may be rebased onto a version that upstream supports. The definition of practicality is left to the judgement of FESCO and the packager.
Interoperability
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.
Examples of this type of package: libopenraw, libimobiledevice, calibre, pilot-link
Database packages
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.
Examples of this type of package: spamassassin, clamav
Examples
- 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 judgement 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).
History
This section is currently a placeholder, but should be used to record examples of actual update scenarios that have been allowed or forbidden for interesting reasons. Those who do not learn from history...