Re: Horde components, deprecating old pear compontent

From: Date: Thu, 10 Nov 2011 14:21:56 +0000
Subject: Re: Horde components, deprecating old pear compontent
References: 1 2 3  Groups: php.pear.dev 
Request: Send a blank email to pear-dev+get-54575@lists.php.net to get a copy of this message
On Thu, Nov 10, 2011 at 12:46 AM, Daniel O'Connor <daniel.oconnor@gmail.com>wrote: > On Thu, Nov 10, 2011 at 1:14 AM, Vasil Rangelov <boen.robot@gmail.com> > wrote: > > > I think it's about time something like PHP's "museum" is created at > > PEAR, so that the "live" package list can be less cluttered with dead > > ones. > > > > What do you think? > > > > > I'm a fan of this, but the community is a bit split. > > See http://pear.php.net/bugs/bug.php?id=17203 and > > > http://old.nabble.com/Re%3A--PEAR-QA--A-'graveyard'-for-packages---unloved-packages-p29589353.html > > > The biggest hurdle is the PEAR installer has no support for a package > migrating channels - if the code vanishes from the PEAR channel; it breaks > people's systems. I've been meaning to take a look at how hard it could be; > but have never had the time really. > > We have deleted some content from SVN or from PEAR, but only when it's had > ridiculously low downloads over 6 years or so and isn't installable at all. > I'm wondering if we can leverage the info in pearweb. E.g. it already notes that a package is superceeded or deprecated in favour of another package. Isn't that pretty much the same? I mean, the channel (aka location) shouldn't matter. Till > > > For the original email; I'd love to superceed any of the below which have > drop in replacements in horde: > > - File_PDF <http://pear.php.net/package/File_PDF> > (lead) > Bugs< > > http://pear.php.net/bugs/search.php?package_name%5B%5D=File_PDF&cmd=display > > > - Log <http://pear.php.net/package/Log> (lead) > Bugs< > > http://pear.php.net/bugs/search.php?package_name%5B%5D=Log&cmd=display> > - Mail <http://pear.php.net/package/Mail> (lead) > Bugs< > > http://pear.php.net/bugs/search.php?package_name%5B%5D=Mail&cmd=display> > - Net_SMS <http://pear.php.net/package/Net_SMS> (lead) > Bugs< > > http://pear.php.net/bugs/search.php?package_name%5B%5D=Net_SMS&cmd=display̗½½Æó¿‹r{è > Þ > > > - Net_SMTP <http://pear.php.net/package/Net_SMTP> > (lead) > Bugs< > > http://pear.php.net/bugs/search.php?package_name%5B%5D=Net_SMTP&cmd=display > > > - Net_Socket <http://pear.php.net/package/Net_Socket> (lead) > Bugs< > > http://pear.php.net/bugs/search.php?package_name%5B%5D=Net_Socket&cmd=display > > > - SOAP <http://pear.php.net/package/SOAP> (lead, > inactive) > Bugs< > > http://pear.php.net/bugs/search.php?package_name%5B%5D=SOAP&cmd=display> > - Text_Diff <http://pear.php.net/package/Text_Diff> > (lead) > Bugs< > > http://pear.php.net/bugs/search.php?package_name%5B%5D=Text_Diff&cmd=display > > > - VFS <http://pear.php.net/package/VFS> (lead) > Bugs< > > http://pear.php.net/bugs/search.php?package_name%5B%5D=VFS&cmd=display> > - XML_SVG <http://pear.php.net/package/XML_SVG> (lead, > inactive) > Bugs< > > http://pear.php.net/bugs/search.php?package_name%5B%5D=XML_SVG&cmd=display > > > > .. plus blog a few migration tutorials if needed (Horde_Log for instance is > quite different); and generally advertise the new APIs to the world. > > This puts us in the right direction for having a "PHP5 friendly" set of > replacements, stops some of the perception that PEAR code is "crufty and > old"; but still supports BC. > Even better; it means that we'll see more PEAR / PEAR2 packages which use > channels :) >

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