From: Ulrich Mueller <ulm@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Cc: glep@gentoo.org
Subject: [gentoo-dev] GLEP 83 "EAPI deprecation" update
Date: Fri, 30 Aug 2024 18:21:57 +0200 [thread overview]
Message-ID: <u1q263rru@gentoo.org> (raw)
[-- Attachment #1.1: Type: text/plain, Size: 191 bytes --]
Deprecation of an EAPI should not be deferred forever. This update of
GLEP 83 will allow it after a longer waiting period of 48 months even if
only one newer EAPI would exist at that point.
[-- Attachment #1.2: 0001-glep-0083-Allow-deprecation-when-only-one-newer-EAPI.patch --]
[-- Type: text/plain, Size: 1782 bytes --]
From a1177143b51a374d0acda06915047b7573203a84 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Ulrich=20M=C3=BCller?= <ulm@gentoo.org>
Date: Fri, 30 Aug 2024 18:09:59 +0200
Subject: [PATCH] glep-0083: Allow deprecation when only one newer EAPI exists
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Signed-off-by: Ulrich Müller <ulm@gentoo.org>
---
glep-0083.rst | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/glep-0083.rst b/glep-0083.rst
index 38b4e57..f542170 100644
--- a/glep-0083.rst
+++ b/glep-0083.rst
@@ -6,7 +6,7 @@ Type: Informational
Status: Active
Version: 1
Created: 2022-06-30
-Last-Modified: 2022-08-14
+Last-Modified: 2024-08-30
Post-History: 2022-07-11, 2022-07-31
Content-Type: text/x-rst
---
@@ -42,7 +42,8 @@ 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.
+* one of them has been supported for 24 months; or
+* one newer Council-approved EAPI has been supported for 48 months.
The Gentoo Council will ban a deprecated EAPI when
@@ -70,7 +71,9 @@ 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.
+immediately. However, deprecation of an EAPI should not be deferred
+forever, so it can be effected after a longer waiting period of 48
+months even if only one newer EAPI exists at that point.
A delay of 24 months between deprecation and ban will give ebuild
authors enough time to update. This is especially relevant for
--
2.46.0
[-- Attachment #1.3: glep-0083.rst --]
[-- Type: text/plain, Size: 5747 bytes --]
---
GLEP: 83
Title: EAPI deprecation
Author: Ulrich Müller <ulm@gentoo.org>
Type: Informational
Status: Active
Version: 1
Created: 2022-06-30
Last-Modified: 2024-08-30
Post-History: 2022-07-11, 2022-07-31
Content-Type: text/x-rst
---
Abstract
========
Introduce standardized criteria for deprecation and banning of EAPIs.
Motivation
==========
So far, old EAPIs were deprecated by the Gentoo Council in an ad-hoc
manner. No fixed criteria were used, resulting in unpredictable
deprecation times after approval of newer EAPIs. Standardized
criteria for deprecation and banning will make the life cycle of EAPIs
more predictable.
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; or
* one newer Council-approved EAPI has been supported for 48 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.
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.
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. However, deprecation of an EAPI should not be deferred
forever, so it can be effected after a longer waiting period of 48
months even if only one newer EAPI exists at that point.
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) manageable, as a
banned EAPI is sufficient reason for updating an ebuild.
Backwards Compatibility
=======================
The following table compares the actual dates of deprecations and bans
[#PMS-PROJECT]_ with the dates that would have resulted from the
criteria proposed in this GLEP ("new date").
==== ========== =========== =========== ========== ====== =========== ========== ======
EAPI Portage Gentoo repo deprecated diff. banned diff.
---- ---------- ----------- ----------------------- ------ ----------------------- ------
\ stable usage < 5 % actual date new date months actual date new date months
==== ========== =========== =========== ========== ====== =========== ========== ======
0 2005-12-26 2017-02-28 2014-02-25 2009-12-11 -50 2016-01-10 2017-02-28 +14
1 2007-12-11 2009-10-25 2013-04-09 2011-01-08 -27 2014-03-11 2013-01-08 -14
2 2009-01-08 2015-03-27 2013-04-09 2012-03-08 -13 2014-03-11 2015-03-27 +12
3 2010-03-08 2015-01-16 2014-02-25 2013-03-17 -11 2016-01-10 2015-03-17 -10
4 2011-03-17 2018-01-11 2015-10-11 2016-01-17 +3 2018-04-08 2018-01-17 -3
5 2012-12-11 2021-06-15 2018-05-13 2018-06-27 +1 2021-08-08 2021-06-15 -2
6 2016-01-17 2022-11-06 2021-07-11 2021-07-05 0 2023-07-05
[*]_
7 2018-06-27
8 2021-07-05
==== ========== =========== =========== ========== ====== =========== ========== ======
.. [*] Extrapolated date, obtained by fitting data between 2021-01-01
and 2022-07-31 with an exponential function.
References
==========
.. [#COUNCIL-20130409] "EAPI deprecation",
Gentoo Council meeting summary 2013-04-09
(https://projects.gentoo.org/council/meeting-logs/20130409-summary.txt).
Note: The original quote says "Repoman" instead of "pkgcheck".
.. [#COUNCIL-20140311] "Ban on EAPI 1 and 2 should extend to updating
EAPI in existing ebuilds", Gentoo Council meeting summary 2014-03-11
(https://projects.gentoo.org/council/meeting-logs/20140311-summary.txt)
.. [#COUNCIL-20091109] "Upgrade path for old systems",
Gentoo Council meeting summary 2009-11-09
(https://projects.gentoo.org/council/meeting-logs/20091109-summary.txt)
.. [#PMS-PROJECT] Gentoo Package Manager Specification project
(https://wiki.gentoo.org/wiki/Project:Package_Manager_Specification#EAPI_life_cycle)
Copyright
=========
This work is licensed under the Creative Commons Attribution-ShareAlike 4.0
International License. To view a copy of this license, visit
https://creativecommons.org/licenses/by-sa/4.0/.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 507 bytes --]
next reply other threads:[~2024-08-30 16:22 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-30 16:21 Ulrich Mueller [this message]
2024-09-01 13:45 ` [gentoo-dev] GLEP 83 "EAPI deprecation" update v2 Ulrich Mueller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=u1q263rru@gentoo.org \
--to=ulm@gentoo.org \
--cc=gentoo-dev@lists.gentoo.org \
--cc=glep@gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox