Re: (Fwd) [PEAR] RE: [PEAR-DEV] dependencies and applications

Zitat von Stefan Neufeind <stefan@neufeind.net>: > On 21 Aug 2003 at 16:03, Jan Schneider wrote: > > > Zitat von Stefan Neufeind <stefan@neufeind.net>: > > > > > As mentioned earlier (but to put it a bit different): > > > Maybe having pear/MDB/MDB.php for all 1.x-releases and from PEAR 1.3 > > > on also have pear/MDB/1.0/MDB.php is fine. From PEAR 2.0 on we can > > > issue the warning as outlined before it still pear/MDB/MDB.php is > > > used. And from 2.5 or so we should finally abandone these warning- > > > files as well. From 1.3 to 2.0 there would be enough time for every > > > package and every programmer out there to update his programs to > > > work without any warnings. And when 2.0 comes out there is still > > > some time until 2.5 finally breaks BC completely. What's so bad > > > about such a solution? > > > > Why not keep the current directory structure for all packages that > > already are released and switch to a new > > Package/VersionNumber/Package.php only for yet to be released packages > > or new major versions. > > > > This way you won't break BC even if in three year you still have an > > application from now depending on a package 1.0 while there is already > > PEAR 3.5 and package 4.1 out. > > > > If you depend on a new major version / new package in your > > application, you will use the new structure. No transition, no bc > > breakage, no version conflicts. > > Another good idea, yes. But does this include that we encourage all > maintainers to release a new major release that follows the new > structure? No, why should we? It's simply not necessary. All that they have to take care is that they use the new structure if the do a major version bump. But this shouldn't be necessary anyway because all packages should be encapsulated by using relative includes. > I think that the packages itself should care about if they > are installed in MDB/... or pear/MDB/2.0/... This could be handled by > the installer. Yes and now. If for some reason this is important for the package, yes. But it shouldn't be (see above). > And I think it's possible to make the transition > "smooth" (as stated in my previous mail). We don't need a transition with my approach. > Meanwhile we could check if > packages internally use relative or absolute paths for dependencies / > includes and suggest to the maintainers to upgrade their packages. > I'd volunteer to check packages and mail the maintainers. Correct, but they don't need to make a new release for that reason. As bc stays for applications, so will stay bc for the existing packages. Jan. -- http://www.horde.org - The Horde Project http://www.ammma.de - discover your knowledge http://www.tip4all.de - Deine private Tippgemeinschaft