Re: Proposals for Sub Packages
| From: | Greg Beaver | Date: | Thu, 23 Mar 2006 15:42:31 +0000 |
| Subject: | Re: Proposals for Sub Packages | ||
| References: | 1 | Groups: | php.pear.dev |
| Request: | Send a blank email to pear-dev+get-41953@lists.php.net to get a copy of this message | ||
Scott Mattocks wrote:
> Hello,
>
> I just proposed Structures_Form which is a base form management class.
> This class requires a front end but the front end is not included in the
> package to make the package more light weight and flexible. Instead the
> front end should be installed as a sub package such as
> Structures_Form_Gtk2 or Structures_Form_CLI. Should the front end
> packages be proposed separately or are they considered part of the main
> package?
This is up to you. In my opinion, this is a good way to do things.
Perhaps the most popular one could be included by default (a la PEAR +
PEAR_Frontend_CLI), but with package.xml 2.0's auto-download of
dependencies, this isn't such a huge issue any longer.
> For example, I created two proposals for PEAR_PackageUpdate. One for the
> base code and another for the PHP-GTK 2 front end. But recently there
> was a thread about Validate saying that Validate sub packages are added
> at the Validate maintainers discretion.
>
> I like the two proposal system because it draws attention to the fact
> that the packages are separate and everything gets more review, but what
> happens if the front end is not accepted but the back end is?
Then you can re-design the frontend and re-propose, withdraw it
altogether, or stage an October revolution :)
Greg