Re: solution for BC breakage

On Tuesday, September 16, 2003 16:42, Tobias Schlitt wrote: > <zitiere wer="Greg Beaver"> >> Hi, > Hi all! >> The answer to the problem of BC is to create a new dependency relation >> called majorversion > I don't think that this is a clean way to deal with the issue. The cleaner > solution is to force people only to change the API on a majorversion and > then to let dependencies only link to a majorversion. > If we allow linking dependencies to subversions, we can run into deep > trouble, if multiple packages link to many different subversions. > Another idea would be to change the structure of the PEAR directory to > reflect majorversions. This would have the advantage, that packages can have > dependencies to different majorversions of a package and have these > installed parallel. We were talking about that time ago. Basically the idea I gave was that each major version of a package should be a subpackage (yes I bought the Greg's idea :-) of a main "empty" package. At the web we'd only see one, ie. MDB package, with releases like MDB-base, MDB2-1.0, MDB3-0.9. Just like some libs/packagers do: # rpm -qa| grep libxml libxml-1.8.17-3 libxml2-2.5.7-1 Of course that would force developers to take care on avoiding file conflicts when installing multiple subpackages. Those maintainers with packages which contains just one file could use XML_Parser2.php and those with many files may choose MDB/v3/MDB.php. Or just standarize it to one way. The documentation of each package should reflect how to call the correct paths for includes. The good news, are that with this idea only the web and package.xml files should be minimaly changed, no deep internals changes required for the installer. -- Tomas V.V.Cox mailto:cox@idecnet.com