Re: Re: New component for QF: selectfilter
| From: | Helgi Þormar | Date: | Thu, 11 Nov 2004 18:28:04 +0000 |
| Subject: | Re: Re: New component for QF: selectfilter | ||
| References: | 1 2 3 | Groups: | php.pear.dev |
| Request: | Send a blank email to pear-dev+get-34336@lists.php.net to get a copy of this message | ||
On Thu, 2004-11-11 at 18:06, Greg Beaver wrote:
> Helgi Þormar wrote:
>
> > I was actually thinking about this very thing today, i.e. the subpackage
> > stuff for QF, IMHO it would be good (at least for QF4) to split some (or
> > even most?) of the elements from the package, at least hierselect,
> > autocomplete and such specific things that are less commonly used and
> > maybe even could benefit from having it's own release cycle :-)
> >
> > Though only a idea, but might be worth it?
>
> This is physically impossible with package.xml 1.0 [1], but package.xml
> 2.0 can be used in conjunction with a trick to make it possible.
Well I was mainly talking about QF4 (not released) thus it will probably
be using v2 of package.xml :)
> It would make things much more complicated at package-time, however, if
> each component is in its own cvs directory like so:
>
> HTML_QuickForm/elements/*
> HTML_QuickForm_element_blah/*
>
> So, I wonder if we should amend the rules about packages to allow
> subpacages to be developed in the main package's subdirectory in certain
> cases?
That's nice in many cases, but I was actually talking about subpackages
in the meaning of that they won't be installed at the same time of QF4,
only if the developer wants the extra stuff (hierselect or something)
then they install it
> Basically, when PEAR 1.4.0 comes out, you will be able to bundle the
> preferred release of a subpackage directly, and specify it as normal
> with a package.xml. Then, in package2.xml, instead use a required
> dependency on the package, and tell the installer to ignore the fake
> bundled packages. This will maintain BC with older PEAR versions, but
> allow newer versions to upgrade only the subpackage, for instance.
That's very cool :)
> Greg
>
> [1] if there are two packages, parent and child that are like so:
>
> parent version 1.0.0:
> file1.php
> file2.php
>
> parent version 1.1.0 (depends on child 1.0.0):
> file1.php
>
> child version 1.0.0:
> file2.php
>
> when you attempt to upgrade from parent 1.0.0 to parent 1.1.0, the
> dependencies will be installed first, and child's file2.php will
> conflict with parent 1.0.0's file2.php, so upgrade will fail without
> --force.
>
> PEAR 1.4.0 fixes this problem by allowing the parent package to specify
> that child is a subpackage, and so files in child can conflict with
> files in parent.