Re: Killing off XML_Tree, or bringing it with us to PEAR2

From: Date: Mon, 21 Sep 2009 07:32:28 +0000
Subject: Re: Killing off XML_Tree, or bringing it with us to PEAR2
References: 1  Groups: php.pear.dev php.pear.qa 
Request: Send a blank email to pear-dev+get-52853@lists.php.net to get a copy of this message
Hi, Daniel O'Connor wrote:
Descision time, people! XML_Tree is used lots.
* File_XSPF
Unmaintained, last beta release 2006-02-15, 2295 total downloads
* LiveUser
Uses XML_Tree for auth and permissions storage, this is pretty isolated and can probably be changed easily.
* LiveUser_Admin
Unmaintained, last beta release 2006-08-22
* Services_ExchangeRates
Unmaintained, last beta release 2009-01-17, 7071 total downloads, 303 downloads for most recent version
* XML_FastCreate
Unmaintained, last stable release 2005-12-15
* XML_FOAF
Unmaintained, last alpha release 2008-08-24, 3593 total downloads, 259 downloads for most recent version
XML_Serializer is the new goodness, but the API changes are reasonable between the two. Lots of the packages which use XML_Tree aren't maintained. Here's the options: 1. Kill it. With fire. Lots of patches / rewriting for the above packages to replace it with XML_Serializer
Looking at the above, the only package worth rewriting is LiveUser, probably LiveUser_Admin also...
2. Version bump to package 2.0, lots of feature requests, kill it off slowly but still have it kicking around so pear2 likes it. 3. Kill them all off.
...and then drop everything else. XML_FastCreate looks downloaded, but it's really ancient with even more ancient dependencies.
Option 1 is my favourite, but the most effort (and look how hard it was to get HTTP_Request2 in place), and needs a migration guide.
You know, it took so long to get HTTP_Request2 in place because getting it in place actually required writing a brand new package. No, make it two brand new packages since Net_URL2 became usable only after Christian Schmidt rewrote it. Here we are talking about migrating from one *existing* package to the other.
Option 2 is the most likely, but we'll have all of the dead weight dragging along. Option 3 is just malicious. Who volunteers to help with 1 or 2?
I'd suggest sweeping the stuff under the proverbial rug: make it invisible on the website and uninstallable. If people come complaining, suggest them to maintain it. Miracles do happen, look at Excel_Writer...

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