https://fedoraproject.org/wiki/EPEL/Changes/Release_based_package_lifetimes
== Summary ==
The change moves expected package lifetime to that of a Red Hat
Enterprise Linux minor release.
== Owner ==
* Name: [[User:smooge|Stephen Smoogen]]
* Email: smooge(a)gmail.com
== Detailed Description ==
Extra Packages for Enterprise Linux is a sub-project of Fedora which
recompiles various Fedora packages against various Red Hat Enterprise
Linux releases. When EPEL was started, RHEL lifetimes were 5 years and
it was thought that the repository could have similarly long
lifetimes. Major rebasing of versions were not to be allowed, and fast
moving software was frowned on.
Over time, the lifetime of a RHEL release grew, and the way RHEL
releases rebased themselved overtime also changed. This has meant that
packagers in EPEL were bound to support software longer than RHEL did
and unable to rebase like RHEL could.
The current proposal is closely linked to release based composes but
does not depend on it. The changes are as follows:
Packagers commit to maintaining software in EPEL for at least one RHEL
minor release or 13 months, whichever is shorter. If a packager needs
to stop maintaining the software, they should do the following
* announce on epel-devel list that they are no longer able to
maintain the package and give the reasons. If someone can take it
over they can do so here.
* release one final version with an additional file named
'README-RETIRED.txt' in the %docs section which says this software
is retired.
* wait until that package arrives in updates.
* let the EPEL release manager know that the package needs to be
retired for the next release.
Otherwise the latest update of the package will be retagged for the
next compose of EPEL and will appear without problems.
If the situation requires a major ABI/API change (security, a new
minor compose occurs, a new LTS package is released) a packager should
announce to epel-devel and put in a ticket in the epel pagure instance
to track. Updates can then be made and will show up in either
/updates/ or the next major.minor compose.
== Benefit to Fedora ==
* Packagers will feel more likely to make their packages available in
EPEL.
* Users of EPEL will have more software and know it is being kept up.
== Scope ==
* Other developers:
* Policies and guidelines: The above need to be coded clearer
* Trademark approval: N/A
== Known Change Impacts ==
== How To Test ==
== User Experience ==
== Contingency Plan ==
* Contingency mechanism: (What to do? Who will do it?)
* Contingency deadline:
* Blocks release?
* Blocks product?
== Release Notes ==
--
Stephen J Smoogen.