On Thu, Apr 8, 2010 at 5:22 AM, Nicholas Clark <nick@ccl4.org> wrote: > On Tue, Apr 06, 2010 at 07:13:27PM +0000, Ævar Arnfjörð Bjarmason wrote: >> On Tue, Apr 6, 2010 at 16:37, Aristotle Pagaltzis <pagaltzis@gmx.de> wrote: >> Meanwhile I set up a bikeshedding page at >> http://www.perlfoundation.org/perl5/index.cgi?batteries > > Is there a plan for the policy on whether modules are ever removed from the > "batteries" version? > > For example, someone commented that DBIx::Class feels like a potential module > to include. If this project had kicked off 8 years ago, then likely back then > it would have been Class::DBI. So, what would happen to a Class::DBI when > DBIx::Class was added later on? Keep both? Phased transition? > > Does Strawberry Perl have a plan for this? Does Task::Kensho? > What does ActiveState do with ActivePerl? Currently Task::Kensho's policy is to "just remove it". Task::Kensho is in theory on a monthly release cycle, and packages come and go between releases as I deem necessary. This is because Task::Kensho specifically states that it isn't a robust enterprise product. It's simply a glimpse of what such a product would possibly look like. I publicly asked for help figuring out what such a product really should be. I got lots of wonderful technical solutions for installing things and not a single volunteer to help me sort out the *social* problem of creating and maintaining a policy on adding, deprecating, and removing packages from an enterprise product. Then I started my own company. Then I got busy. > And I'd love to see someone or some group prototype this. > Branch http://github.com/mirrors/perl and get cracking. So would I. I would even try to make people like mst and the EPO well volunteer people to help. -ChrisThread Previous | Thread Next