devel update on PEAR 1.4.0, 1/23/2004

Hi, Good news on several fronts. First, I just returned from a very successful recording project with my quartet (yay). Now, much more interesting to you all, I had a fair amount of free time to test out several things, and as some of you following pear-cvs or pear-core may have noticed, several hurdles to PEAR 1.4.0a1's release have been surmounted. 1) pearweb is 100% ready to accept packages using package.xml 2.0 format. This is a huge deal, as I didn't think it would be a simple modification until a brilliancy last week with regards to a minor modification to package.getDownloadURL() fixed everything. This is fully tested on my local setup. However, I would expect a few minor kinks along the way, especially with regard to dependencies. 2) PEAR_PackageFileManager no longer kacks if you have PEAR 1.4.0a1 installed and are using simpleoutput. However, the simpleoutput option puts baseinstalldir in every file tag, and the solution, although simple, is non-trivial, so I haven't yet coded it fully. 3) I've modified PEAR_Frontend_Web to work with package.xml 2.0 install, and much more exciting, with CHANNELS! There is a new channels modification section, and you can list them, add a new one, remove one you don't like, etc. Full support is there. I of course am not a lead on PEAR_Frontend_Web, so once the behind-the-scenes stuff is worked out, it should be good to go. 4) I've almost finished modifying PEAR_Frontend_Gtk to work with package.xml 2.0. The main issue is I don't have a stable testing environment or a real knowledge of gtk, but I'm getting there (Alan, any time to help out on this one in the next couple of weeks? I just need to add a few things to make it do the acrobatics that PEAR_Frontend_Web is now capable of doing) 5) A re-thinking of install scripts resulted in the removal of the preinstallscript task (it isn't really pre-install anyways) and the revamping of the postinstallscript. The problem is that these scripts require multi-session install capabilities in the web installer, which means that temporary files and so on must persist until the conclusion of the install script. Major headache, but moving the parameters to xml definitions in package.xml turned out to be simple, elegant, and ridiculously powerful. This will also cut down on script errors as script-level parameter errors will be caught right in package.xml validation. This means that the only remaining hurdles to the release of PEAR 1.4.0a1 are the following: - release of PEAR_PackageFileManager with support for PEAR 1.4.0 - release of PEAR_Frontend_Web and PEAR_Frontend_Gtk I've decided that even though 100% of unit tests are not yet complete, it's time to get busy. You all deserve access to the ridiculous number of minor and major bugs in PEAR 1.3.x and earlier that have been fixed with internal design changes in PEAR 1.4.x. Not to mention channels and nifty thingos in package.xml 2.0 It should (must) be noted that when PEAR 1.4.0a1 is released, package.xml 2.0 will be considered alpha as well. I don't think it will be necessary to go through the rigmarole of 2.0.0a1, etc. Instead, as changes are deemed necessary, I will simply increment to 2.1, and so on. This will be a simple way to handle things. Releases that use package.xml 2.0 cannot be more stable than PEAR, so keep that in mind as you plan to use the new features. For discussion of more detailed roadmap, check out the pear-core list where I am about to write. Greg