m (moved User:Kevin/new EPEL Updates Policy to EPEL Updates Policy: moving live) |
mNo edit summary |
||
| (6 intermediate revisions by 5 users not shown) | |||
| Line 1: | Line 1: | ||
'''THE EPEL WIKI PAGES ARE NO LONGER USED AND ARE OUT OF DATE - SEE [https://docs.fedoraproject.org/en-US/epel/ THE EPEL DOCS] FOR UP TO DATE INFORMATION.''' | |||
(These wiki pages are being kept for historical reference only.) | |||
= EPEL Updates Policy = | = EPEL Updates Policy = | ||
This document describes the policy for updates to packages in the EPEL package collection. | This document describes the policy for updates to packages in the EPEL package collection. For general EPEL package guidelines, refer to the [[EPEL/GuidelinesAndPolicies|EPEL Guidelines and Policy]] page. | ||
== Beta Releases == | == Beta Releases == | ||
When a new Enterprise Linux major version (example | When a new Enterprise Linux major version (example 7, 8, 9) is being tested and has been released as a open Beta version, EPEL will create a Beta EPEL collection version against that release. This branch will follow a process much like Fedora's rawhide repository. Packages built in this Beta EPEL will be signed and pushed out each day. There will be only one repository (no testing). Packages in this Beta collection could be removed, or updated in an incompatible manner if needed before the collection is released as stable. At some point after the Enterprise Linux version is released, EPEL will leave Beta status and move to a stable model for this collection. | ||
== Stable Releases == | == Stable Releases == | ||
| Line 15: | Line 19: | ||
* All updates should strive to avoid situations that require manual intervention to keep the package functioning after update. | * All updates should strive to avoid situations that require manual intervention to keep the package functioning after update. | ||
* Major updates with changes to user | * Major updates with changes to user experience are to be avoided. If they cannot be avoided, the [[EPEL incompatible upgrades policy]] MUST be followed. This includes two separate announcements to the epel-announce mailing list. | ||
* When new packages enter the Enterprise Linux distribution that is already available in EPEL, that package will be marked dead.package and blocked in pkgdb and koji. | * When new packages enter the Enterprise Linux distribution that is already available in EPEL, that package will be marked dead.package and blocked in pkgdb and koji. | ||
== Exceptions == | == Exceptions == | ||
In some rare cases, exceptions will need to be made. Bring your case before the EPEL SIG at one of the weekly meetings and/or the epel-devel mailing list. Possibly grounds for exception might include: | In some rare cases, exceptions will need to be made. Bring your case before the EPEL SIG at one of the weekly meetings and/or the {{fplist|epel-devel}} mailing list. Possibly grounds for exception might include: | ||
* Serious security issue that cannot be backported to the existing version, so a new major version is required. | * Serious security issue that cannot be backported to the existing version, so a new major version is required. | ||
| Line 28: | Line 32: | ||
In cases of major disruption, EPEL updates will looked to be done along with Red Hat Enterprise Linux minor releases (6.1, 6.2, 6.3) so as to allow for longer testing or differing beta testing. | In cases of major disruption, EPEL updates will looked to be done along with Red Hat Enterprise Linux minor releases (6.1, 6.2, 6.3) so as to allow for longer testing or differing beta testing. | ||
[[Category:EPEL]] | |||
Latest revision as of 20:02, 6 January 2022
THE EPEL WIKI PAGES ARE NO LONGER USED AND ARE OUT OF DATE - SEE THE EPEL DOCS FOR UP TO DATE INFORMATION.
(These wiki pages are being kept for historical reference only.)
EPEL Updates Policy
This document describes the policy for updates to packages in the EPEL package collection. For general EPEL package guidelines, refer to the EPEL Guidelines and Policy page.
Beta Releases
When a new Enterprise Linux major version (example 7, 8, 9) is being tested and has been released as a open Beta version, EPEL will create a Beta EPEL collection version against that release. This branch will follow a process much like Fedora's rawhide repository. Packages built in this Beta EPEL will be signed and pushed out each day. There will be only one repository (no testing). Packages in this Beta collection could be removed, or updated in an incompatible manner if needed before the collection is released as stable. At some point after the Enterprise Linux version is released, EPEL will leave Beta status and move to a stable model for this collection.
Stable Releases
Once a Enterprise Linux is released, and EPEL has left Beta and entered it's stable phase the follow applies:
- All updates MUST spend at least 2 weeks in the testing repository, or +3 karma from testers.
- All updates should strive to avoid situations that require manual intervention to keep the package functioning after update.
- Major updates with changes to user experience are to be avoided. If they cannot be avoided, the EPEL incompatible upgrades policy MUST be followed. This includes two separate announcements to the epel-announce mailing list.
- When new packages enter the Enterprise Linux distribution that is already available in EPEL, that package will be marked dead.package and blocked in pkgdb and koji.
Exceptions
In some rare cases, exceptions will need to be made. Bring your case before the EPEL SIG at one of the weekly meetings and/or the epel-devel mailing list. Possibly grounds for exception might include:
- Serious security issue that cannot be backported to the existing version, so a new major version is required.
- Serious bugs that cannot be fixed in the existing version.
In cases of major disruption, EPEL updates will looked to be done along with Red Hat Enterprise Linux minor releases (6.1, 6.2, 6.3) so as to allow for longer testing or differing beta testing.