On 11/07/2014 03:13 AM, Rich Freeman wrote: > On Thu, Nov 6, 2014 at 5:03 PM, Zac Medico <[email protected]> wrote: >> On 11/06/2014 01:53 PM, Rich Freeman wrote: >>> On Thu, Nov 6, 2014 at 3:11 PM, Michał Górny <[email protected]> wrote: >>>> >>>> # This eclass contains backports of functions that were accepted >>>> # by the Council for the EAPI following the EAPI used by ebuild, >>>> # and can be implemented in pure shell script. >>> >>> I'm not sure that I like this sort of a moving-target definition. >>> When EAPI6 is out, do you intend to have the eclass die at some point >>> for any packages using EAPI5? >> >> We should be able to simply migrate consumers to the new EAPI, then >> deprecate future.eclass. >> > > Deprecate it? But what about providing EAPI7 support for EAPI6 > packages? The description doesn't say that the eclass is intended to > provide EAPI6 support for EAPI5 packages - it says that it is intended > to provide EAPIn+1 support for EAPIn packages.
Okay, then we could number the future eclasses by EAPI. Like future-eapi-6, future-eapi-7, and so on. > Of course, this approach tends to make the assumption that EAPIs are > orderable, which isn't actually something anybody has committed to as > far as I'm aware. The next EAPI /could/ be named "webapp-1" and only > be used for web applications. Granted, there have been no plans to > date to deviate from the linear EAPI history we've maintained so far. We could also add a future-eapi-webapp-1 eclass. > 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. > There is no guarantee that moving > to the actual new EAPI won't break something, and packages that don't > move become blockers for the eclass being able to move on to the next > EAPI. -- Thanks, Zac
