Re: DB getRow() argument order

The new BC system is in place to handle BC breaks. Breaking BC and posting an announcement is not going to solve most situations that I've used PHP professionally. There is a large subset of coders who are paid to maintain their own code full-time, but even in these situations, there is turnover, and those who don't know code might have to waste a few days tracking down a problem due to a well-documented BC break. I recently had a former client email me and say "gee, uploading an image to the form you built doesn't work" I put in some extra time I didn't have to find and fix the bug, and it turned out to be a BC break in HTML_Quickform which was very well documented. At the time I wrote the code, the method I used was not deprecated. By the time it was deprecated and removed, I had completely forgotten about using it for the old project. I also did not have access to the system PEAR install or ability to do a local install (no shell or access to the live web, only the devel version). Basically an annoying situation, but it paid :). Fixing the BC break was easy once I knew what it was, also because of excellent documentation in HTML_QuickForm (thanks guys!), but the situation would not have been a problem under the new BC system. Documentation solves lots of things, but not everything, otherwise phpDocumentor would be the most important package ;). However, I do think having specific lists for a package or category would make sense, and I believe Martin is going to do this. Question number 2: $ pear install Package-1.3 this will install version 1.3 of Package. Incidentally, version 1.4 will have the convenient "revert" command to allow a quick undo of a faulty package upgrade day 1: $ pear install Package-1.3 day 3: "uhoh, the finance subsystem is broken because of Package 1.3" $ pear revert Package reverting to previously installed version Regards, Greg Hans Lellelid wrote:

Lukas Smith wrote:

Touchy subject. A BC break is a BC break, especially if it doesnt fix a bug this one is quite clear. The thing is just because the recommended way changed a while back doesnt mean that people actually changed their code. Noting this in the changelog is not going to help the people that just want the latest bug fixes and not the latest BC break. Therefore its actually a clear no.

I think it would be really nice to have a package announcement / distribution list, so that if a change like this is going to be made (and it definitely sounds like probably no one is needing the extra param checking logic in getRow()) it could be broadcast to everyone who was registered to receive notices for the package. This could also cover security notices, etc. I use PEAR in production environment for work. I've definitly been burned (i.e. sites break) when upgrades in PEAR do break things -- like latest HTML_TreeMenu no longer working on Safari, all of a sudden. But on the other hand I would be completely fine w/ BC breaking changes as long as I knew about them -- and didn't have to go mucking through the changelog to make sure. I would be one of those people who would definitely register for such announcements for the packages that I use. Also, I think it would be nice if there could be some sort of "what may break!" section of the package.xml that would be manditorily displayed when you upgrade a package using the PEAR installer. Also -- and this is just me being ignorant -- how do you specify the version using the PEAR installer? I have not figured that one out yet... Hans