Ulrich Mueller posted on Sun, 31 Jul 2022 23:26:13 +0200 as excerpted:
Update v3
One language thing and two possible clarifications.
---
GLEP: 83 Title: EAPI deprecation
Author: Ulrich Müller <ulm@gentoo.org>
Type: Informational Status: Draft
Version: 1
Created: 2022-06-30
Last-Modified: 2022-07-31
Post-History: 2022-07-11, 2022-07-31
Content-Type: text/x-rst
---
Specification =============
A *deprecated EAPI* is no longer required for the upgrade path of users' systems. Its use is discouraged, and tools like pkgcheck will warn
about this [#COUNCIL-20130409]_.
A *banned EAPI* must no longer be used, neither for new ebuilds, nor for updating of existing ebuilds [#COUNCIL-20140311]_.
The Gentoo Council will deprecate an EAPI when
* two newer Council-approved EAPIs are supported by the stable version
of Portage, and
* one of them has been supported for 24 months.
The Gentoo Council will ban a deprecated EAPI when
* 24 months have passed since its deprecation, and * it is used by fewer
than 5 % of ebuilds in the Gentoo repository.
The first possible clarification fits here (I think). Something like:
This GLEP is intended as a policy reference guide for EAPI minimum effective times. Despite the statistical qualifications listed here no EAPI
will be deprecated or banned without specific Gentoo Council action.
(While this is implied by the "Gentoo Council will..." wording, making it explicit could prevent later confusion/controversy.)
EAPIs used in profiles are outside the scope of this GLEP.
Rationale =========
Timing of EAPI deprecation is a trade-off between different factors.
On the one hand, the total number of EAPIs in active use should be
limited; this will prevent the learning curve for new developers and contributors from becoming too steep and will help to reduce code
complexity, e.g. in eclasses.
The language point:
Am I the only one for whom the omission of "from" makes the sentence read smoother? (Maybe it's a regional English thing?)
; this will prevent the learning curve [...] from becoming too steep...
; this will prevent the learning curve [...] becoming too steep...
On the other hand, an upgrade path to a stable system is guaranteed for
one year, plus limited support for systems that are outdated more than a
year [#COUNCIL-20091109]_. Therefore, previous EAPIs are still required during that time. A period of 24 months before deprecation has been
chosen, which is more than the required minimum and will allow projects
to support a longer upgrade path.
Requiring two newer EAPIs before deprecation will allow ebuilds that are otherwise seldom updated to be bumped to the next but one EAPI
immediately.
A delay of 24 months between deprecation and ban will give ebuild
authors enough time to update. This is especially relevant for overlays
and downstream distributions. An additional requirement for banning an
EAPI is that fewer than 5 % of ebuilds are using the EAPI in question.
This requirement is defined to help keep the number of ebuild updates
(and bug reports requesting them) managable, as a banned EAPI is
sufficient reason for updating an ebuild.
The second possible clarification seems to fit about here, but may require
a bit of adjustment to the text above it.
The two 24-month times are effectively additive, yielding a total 48 months minimum between addition of an EAPI and banning of the previous one. Given past EAPI history of at minimum a year between EAPI introductions that should yield a minimum three years of active EAPI life before deprecation, one year minimum as the newest EAPI plus two years before deprecation, plus two years
of deprecation, for five years total EAPI life before ban.
(This isn't entirely necessary but makes explicit the answer to one of my first questions reading the proposal. YMMV. I debated spec vs rational, but decided rational was a better fit.)
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)