Re: Killing off XML_Tree, or bringing it with us to PEAR2
| From: | Alexey Borzov | 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.Unmaintained, last beta release 2006-02-15, 2295 total downloads* File_XSPF
Uses XML_Tree for auth and permissions storage, this is pretty isolated and can probably be changed easily.* LiveUser
Unmaintained, last beta release 2006-08-22* LiveUser_Admin
Unmaintained, last beta release 2009-01-17, 7071 total downloads, 303 downloads for most recent version* Services_ExchangeRates
Unmaintained, last stable release 2005-12-15* XML_FastCreate
Unmaintained, last alpha release 2008-08-24, 3593 total downloads, 259 downloads for most recent version* XML_FOAF
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_SerializerLooking 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...