EPEL Updates Policy

EPEL Updates Policy

This document describes the policy for updates to packages in the EPEL package collection.

Beta Releases

When a new Enterprise Linux major version (example 4, 5, 6, 7) 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 experence are to be avoided.

• 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.