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.