-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2009.06.10 22:21, Tobias Scherbaum wrote: [snip]
> The main "problem" is that there is no deployment process for newer > EAPIs specified right now. In the past we had something like "there > must be two releases (stage sets) including a Portage version > supporting new features" before people were allowed to use new > features in tree. We had a timeframe of something about a half year > between introduction of new features and usage of them. At least in > theory. > > While having such a longer timeframe would make the deployment of new > EAPIs somewhat easier (especially the special cases when newer > versions of a package were migrated to a shiny new EAPI which isn't > supported by a stable Portage yet and there's a need for quick > versions bump due to security bugs) I think something inbetween that > old process and the > currently used one would be useful. For example something like: New > EAPIs can be used in tree once a Portage version supporting that > specific EPAI has been marked as stable plus a transition period of - > say - 4 weeks after the Portage version has been made stable on the > first architecture. What about the case where the new EAPI breaks backwards compatibility with existing package managers, as would be the case with glep 55? Its quite true that such changes can be introduced after a wait and only upset late adoptors. By implementing the key feature of glep 55, which is making the EAPI known to the PM without sourcing the ebuild, we would only need one last wait to introduce new features in this way in later EAPIs.PMs would then know the EAPI in advance and ignore ebuilds using EAPIs they don't understand. [snip] > > Tobias > > - -- Regards, Roy Bamford (NeddySeagoon) a member of gentoo-ops forum-mods treecleaners trustees -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (GNU/Linux) iEYEARECAAYFAkowMGEACgkQTE4/y7nJvaswcgCfUa5dKLY8YYMyL7FjhIcNVXJg pO8An33Z2+1lm2jzkh9ciANzOhH+PqXv =yiKg -----END PGP SIGNATURE-----
