On Sunday 17 May 2009, Piotr Jaroszyński wrote:
> Hello,
>
> I have just updated GLEP 55 [1], hopefully making it a bit clearer.
>
> Just FYI, my order of preference of solutions is:
>
> 1. EAPI-suffixed ebuilds (obviously)
> 2. EAPI in the filename with one-time extension change
> 3. Easily fetchable EAPI inside the ebuild and one-time extension
> change

Judging from this list, fourth option present in the GLEP is 
unacceptable for you?
4. Easily fetchable EAPI inside the ebuild

From what I understand, the difference between 3 and 4 is that

(4) would break pre-glep55 Portage versions that see an ebuild with no
    metadata cache present if the ebuild uses a future EAPI that 
    introduces changes as described in the "Current behaviour" section.
(4) would otherwise keep the current workflow the same except 
    restricting the way the EAPI variable is defined in the ebuild.

I would argue that most people who are be exposed to repositories that 
do not carry a metadata cache (overlays) which use new EAPIs also keep 
their portage version current. I'd say go with option (4) now and by 
the time EAPI 4 is collected, written up, agreed upon and implemented, 
enough time went by so we would not have to introduce an artificial 
delay.
And after that, there won't be any delay to avoid breakage anymore.


Robert