-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 30/08/12 09:14 AM, Rich Freeman wrote: > On Thu, Aug 30, 2012 at 9:04 AM, Ian Stakenvicius <a...@gentoo.org> > wrote: >> >> The primary benefit to the policy that dev's should bump EAPI >> when bumping ebuilds is so that older inferior EAPIs can be >> deprecated and eventually removed from the tree. > > What is the benefit from removing the old EAPIs?
Simpler eclasses is the first thing that comes to mind. Consistency in the way the dependency tree is built would be another (when newer EAPIs address such things, that is) > > Simply bumping an ebuild to EAPI=5 doesn't even guarantee that > either of those features would be used anyway. ..although this could technicaly be true, I think most developers would assume that bumping EAPI doesn't mean changing the EAPI variable from whatever to 5 and that's it; the "bump" should involve integrating any applicable features that the new EAPI offers. > > If there is a benefit from some specific practice, then let's > adopt it. However, I don't think that is the same as just bumping > EAPIs for their own sake. > > When there is a benefit to adopting a new EAPI of course > maintainers should try to take advantage of it. If there are > specific changes we want to try to make tree-wide let's try to do > that too. But, why bump ebuilds from 0 to 1 to 2 to 3 to 4 to 5 > when your only example of an end-user benefit would have been > achieved if we just bumped from 0 to 5 in one step? We used to have a policy that the oldest EAPI that implements all features needed for an ebuild is the one that should be used. Now (as of when EAPI=4 was made official i think?) it's the reverse -- the newest (official) EAPI is the one that should be used. All this policy change suggestion scarabeus provided is doing, is recommending that developers bump EAPI when they bump their ebuilds, as compared to only when writing new ones (which is all the current policy would require us to do). if you want another example, i'm sure end-user benefits would have ensued if many existing packages that die in pkg_setup were bumped to EAPI=4 right away and their checks moved to pkg_pretend. Examples prior to EAPI=4 are irrelevent as the policy was different then. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAlA/a6sACgkQ2ugaI38ACPBO5wD+JSBmTT3j0MFc1GMjIDatRLnV J7Oj3rQWjS3GKpU8pQgBALsVg7R1QGGjETv0KS3j9yxBlflr4PlKECboVXqoRupL =+zxo -----END PGP SIGNATURE-----
