On Fri, Nov 7, 2014 at 1:01 PM, Zac Medico <[email protected]> wrote: > >> I'm still concerned that in general we tend to have packages hang >> around at older EAPIs for a long time as it is. That isn't really a >> problem if those EAPIs are stable and supported for a while. This >> seems likely to complicate things. > > Sure, it could. However, it should be pretty manageable if we use a > separate future eclass for each EAPI. >
I am still a bit uneasy, but I definitely agree that if we do this I'd much rather see a series of versioned eclasses than an eclass whose functionality changes in place over time. Ulm's point still exists that technically EAPI6 isn't actually approved yet, in part because the agreement was that nothing gets approved for good without a reference implementation in portage. So, there is some risk that it could change, which might mean that ebuilds that use future.eclass would need more work when moving them to an EAPI that no longer contains the function they call. That said, the whole point of the council vote was to avoid having the PM teams spending time on features that were going to get voted out at the last minute. Assuming that all goes as planned the actual PMS vote should be a formality, but you know how plans go... :) -- Rich
