Re: [RFC] BC breakage in PEAR - how to handle it properly

Stefan Neufeind wrote:

If we use the current model that even 2.x will be the same package than 1.x we can solve this problem by adding an implicit (if not otherwise given) "lt" in the installer, right? This will work for Alexey's first three minor BC breakage examples, and I am in favor of it. I would like to see major version increases reserved exclusively for major API changes. Minor version increases to a 100 boundary could be used for minor BC breaks, then an implicit lt will work (version 1.x < 1.100, for example)

If a major BC break occurs, then the package should be released as a new package as detailed below.

Hmm, I don't think this is a good solution since if you demand that the version 1.x-packages still be existant in the repository there would be MUCH confusion about e.g. MDB, MDB2, MDB3, ... We've already developed the idea of having multiple major versions under the same package name. So if you try to install the package without giving a major version to the installer you will install the latest but can optinally also pass (or automatically pass) a major version to install. This sounds more usable and clean to me. We once though about having a directory-structure like

MDB/MDB.php    -> just an include to the latest MDB-version

MDB/v1/... MDB/v2/... How about this approach? This is not backwards-compatible with any previously installed packages - a serious problem.

I think that Tomas's note- MDB 1.x will always be version 1.x, and MDB2 will always be version 2.x will solve any confusion. If that sounds good, I'll revise the RFC and re-post it.

Hmm, thinking about all consequences I see another problem which we should keep in mind: What if we use two packages where one still relies on e.g. MDB 1.x and the other relies on MDB 2.x? Then a "require_once" would work but the class MDB is "already defined" and would therefor lead to problems, right? Any solutions to this? Yes - the solution I proposed would name MDB2's *class* MDB2, not MDB. I want to preserve the relationship of path => classname.

This is another reason why it is the only viable solution. Regards, Greg