Re: package.xml 2.0 dilemma

Alan Knowles wrote:

I dont really mind the fixed ordering, I was concerned that a) licence was inconviently located for changelog management. b) that the lack of a 'release' block made maintaining a changelog more work than previously. c) that without using the packagermanager application, I would have to maintain 2 package files. If the packager creates a strictly ordered file when packaging (eg. current 2.0 format along with generating a 1.0 format file for BC.) based on the user defined less strict 2.1 format.. It would solve alot of these issues...

How about this solution: tweak the schema to allow license to appear in either the current location or the location preferred by you. This will open up the possibility for two <license> tags, but I don't think it's a huge deal as long as PEAR catches it. There's no solution for (c) unfortunately. This is a convenience for PEAR 1.3.5 and older users. Once 1.4.0 stable is out, you can elect to only maintain package.xml version 2.0 if it is a real hassle. I've been maintaining the package-PEAR.xml and package2.xml for a while now, and it seems to work just fine by hand once you have the files in place. For a simple package like the svn extension, I would recommend simply maintaining the package.xml 1.0 and use "pear convert" to spit out an equivalent package.xml 2.0. Greg