RE: [PEAR-DEV] BC breakage results

> OK, here is HTML_QuickForm. After its 3.0 release (it was 3.0 due to > MAJOR additions, not due to huge BC breaks) several methods were marked > as deprecated, with new API available for the same purposes. As of 3.1 > these methods throw errors if called, but still finish their job. > > Now, we have a dilemma: either remove them in 3.2 (which was intended > initially), make the version 4.0 instead of 3.2 (which will be > misleading for users after 3.0) or create an abomination of QuickForm4. > Removing them will shave 10kb from the main include file, which is Good. > > Please note that the packages depending on QuickForm do not use these > methods, they are not used in the package's examples and they are > clearly marked as deprecated in docs. > Even if NOTHING that depends on QuickForm in PEAR (all we know about is what is in PEAR, not what the users have done), then the API should still be available until 4.0. Be it via some sort of compatability setup, or whatever. Deprecating them inside of a subrelease, OK. Returning errors or removing them, BAD. > > This is what I call "minor BC breakage". Your solution for it would be?.. > Minor BC breakage is changing a parameter type because of a bug, or the name of a function because you realised that you overloaded something that you shouldn't have. This is clearly not a bug, it was a descision to change the API in QuickForm. > Having compatibility layers is cool, but PHP is unfortunately > interpreted and doesn't even have bytecode compiler by default. > That doesn't prevent you from having these classes do nothing but call the new ones, unless the partameters have changed. And again, that would be major BC breakage. > > Were this changes ever communicated to you in advance? Exactly my point. Doesn't matter if you have a job and are able to contribute only a few hours per month to pear... Thanks, Rob