On Thu, Nov 6, 2014 at 5:03 PM, Zac Medico <zmed...@gentoo.org> wrote: > On 11/06/2014 01:53 PM, Rich Freeman wrote: >> On Thu, Nov 6, 2014 at 3:11 PM, Michał Górny <mgo...@gentoo.org> 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. 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. 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. 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. -- Rich
