Re: Re: New component for QF: selectfilter

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. 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? 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. 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.