| Line 1: | Line 1: | ||
= 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 == | ||
Revision as of 14:08, 8 August 2014
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 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.