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