On 27.07.2011 17:30, Chí-Thanh Christopher Nguyễn wrote: > Donnie Berkholz schrieb: >> Eclasses still shouldn't break backwards compatibility — that hasn't >> changed in the past 5 years, despite what a very small minority of >> devs appears to think. This has been a huge PITA for python.eclass in >> particular, which has broken tons of my ebuilds for no particular >> reason. (And no, a 30-day warning is not an excuse for breaking >> anything.) If you need to edit an eclass for EAPI/API changes anyway, >> updating the inherit line to "python-2" instead of "python" isn't a >> big deal. In the general sense, I think changing the API in arbitrary >> ways based on the EAPI in use is just plain confusing, and it should >> go into a new version-bumped eclass instead. > > I think making the eclass behave differently on new EAPIs is not a bad > way to deprecate old functions. It will not break any existing ebuilds. > Only if you touch the ebuild and change the EAPI things may break, but > then the ebuild has your attention anyway. >
I agree there's no problem with small deprecations with new EAPIs as long as they are handled properly (it doesn't break backwards compatibility) so that ebuilds authors notice they must change things. If the eclass turns into a wholly different thing then it should rather be a new eclass. Regards, Petteri
signature.asc
Description: OpenPGP digital signature
