Re: (Fwd) [PEAR] RE: [PEAR-DEV] dependencies and applications
| From: | Stefan Neufeind | Date: | Thu, 21 Aug 2003 14:16:46 +0000 |
| Subject: | Re: (Fwd) [PEAR] RE: [PEAR-DEV] dependencies and applications | ||
| References: | 1 | Groups: | php.pear.dev |
| Request: | Send a blank email to pear-dev+get-20265@lists.php.net to get a copy of this message | ||
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? 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. And I think it's possible to make the transition
"smooth" (as stated in my previous mail). 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.
Stefan