Re: Proposals for Sub Packages

From: 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

« previous php.pear.dev (#41953) next »