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.
Stable Releases
-
All updates MUST spend at least 1 week 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 Steering Committee at one of the weekly meetings and/or the 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 (8.1, 8.2, 8.3) so as to allow for longer testing or differing beta testing.