Re: BC breakage results

Hi! Jan Schneider wrote:

That doesn't help at all. It's not hard to notice that the time spent by the several PEAR developers or even PHP user differ drastically. Take the PEAR developer Doe who's working night and day on his packages and release a new (breaking) version every month. A dozen other developers depend on each of his 5 packages and each of these developers has 500 users of their software. You really want these 30,000 people to keep up with this PEAR devloper's development speed just to make sure that nothing breaks their software? Cool idea.

As I already said, if the package maintainers do not want to follow the development of its dependencies, they should *explicitly* mark this in their package.xml, automagic "solutions" are just camouflage for this. As for the users, they *should* read changelogs before upgrading. That's all. If developer Doe does not mark BC breakage in changelogs, then there is PEAR Group to punish him.

For the record: I don't think that we should require x.0 releases for each minor BC breakage. Or else some PEAR packages risk reaching 20.0 quite soon.

And? What's wrong with that? And btw, if you design you package well you don't have to break bc that often, not mentioning that you have the whole beta lifetime to mature your api, you can always add new methods without bc breakage and there several ways like compatibility layers that avoid bc breakage even if you change your API.

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. This is what I call "minor BC breakage". Your solution for it would be?.. Having compatibility layers is cool, but PHP is unfortunately interpreted and doesn't even have bytecode compiler by default.

The question is: won't this structure add more problems than it is trying to solve? I haven't seen much complaints about BC breakage from PEAR users, only from few PEAR developers...

Because the PEAR developers are the middle men. And because most of the PEAR users are actually developers themselves. Do you have any idea how much user complaints/frustration we have or had to handle on the Horde mailing lists because of disappeared HCEMD5.php, Select.php or Span.php files or missing DB::isWarning() methods?

Were this changes ever communicated to you in advance? Exactly my point.