>>>>> On Mon, 11 Jul 2022, Ulrich Mueller wrote: > Please find below the first draft of GLEP 83 "EAPI deprecation". > This tries to define criteria for deprecation and for banning of EAPIs > by the Council.
> I have tried to model it in a way that the actual dates for at least > EAPIs 4 and 5 are reproduced within a few months. To this end, the > criteria depend on three parameters: > - time between EAPI n+1 support by stable Portage and deprecation > of EAPI n (24 months) > - time between deprecation and ban (24 months) > - fraction of ebuilds in the tree when banning (< 5 %, at present > corresponding to about 1500 ebuilds) > The first two parameters can be varied within a relatively wide range, > without much influence on the timing for EAPIs 4 and 5. Combinations > like 30/24 months, 30/18 months, 24/18 months, or even 36/12 months > would work as well. I guess the question there is if we prefer a longer > upgrade path and transition times, or a smaller number of EAPIs in the > tree. To get the discussion going, the crucial parameter is the time between deprecation and ban. If my extrapolated date for the number of EAPI 6 ebuilds falling below 5 % is at least somewhat accurate (2022-11-22), then EAPI 6 would be banned: - with 24 months time between deprecation and ban: July 2023, - with 18 months time between deprecation and ban: January 2023, and - with 12 months time between deprecation and ban: November 2022. I believe that this wouldn't much affect removal of ebuilds from the tree, but it might have other consequences. For example, it has been suggested that we link EAPI support in eclasses to that status, i.e. we wouldn't remove support until an EAPI becomes banned. So, any opinions? Should we go for the longer transition time (and make overlay maintainers happy), or for a shorter time so that we can tidy up eclasses sooner? Ulrich
signature.asc
Description: PGP signature
