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

Well Greg, now that someone brought the subject up again I remember we wanted to discuss that in more depth anyway around this time :-) So here go my thoughts ... On 17 Sep 2003 at 19:08, Greg Beaver wrote: > [RFC] BC breakage in PEAR > Sep. 17, 2003 > Greg Beaver > > Problem: > BC breakage in PEAR has not been addressed. If one package depends on > version 2.x of a package, and another depends on version 1.x, one > package loses in the end. version 1.x can't be installed with version > 2.x. > > Solution: > If a minor BC break occurs, or BC is maintained, but a package is > completely re-written, a major version number should be incremented in > package.xml, and current PEAR systems already in place should be used. > The installer should be modified so that a <dep rel="ge" > version="1.5"> will fail if the major version is > 1, unless another > explicit <dep rel="lt" version="3.0"> is specified. 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? > 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? > The solution requires effort on the part of developers only. No > changes need be made to the installer, and no changes need be made to > package.xml. Hmm - you are right, but I don't this this is the best solution ... at least, I'm not convinced. [...] 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? Stefan