package.xml 2.0 - consider carefully

Hi all, I have a potential solution for Alan's issue, since he only thought 1 tag was out of place. Before we make any changes to package.xml 2.0, I want to satisfy one question: Are these changes cosmetic, or truly functional? At this stage, making cosmetic changes to package.xml that break BC is probably not the greatest idea. Alan's original point was that hand-creating changelog entries is more difficult with the current setup, as the <license> tag is further down than it used to be. Of course, I tried to base the ordering on the way PEAR_Common::xmlFromInfo() spits out package.xml 1.0, but can see the point of putting commonly changed information further down to aid in changelog creation. However, I would also like to point out that I have been creating changelogs in PEAR's package2.xml simply by copying the previous changelog entry, and then changing the release date and notes. In other words, slightly different methodology yields the same ease of updating the package.xml by hand. Does that mean Alan's request is cosmetic? I would rather pose the question to you all than give my own opinion so that the final decision is more of a quorum. If we do break BC on package.xml 2.0, I would like it to be an important functional change. For instance, the <max> tag in the php dependency was originally something I hoped would prevent problems upgrading to PHP 6 the way PEAR packages upgraded to PHP 5, but as time went on, it turned out that PEAR's QA was much more effective at enforcing PHP 5 compliance than anything else. So, in 1.4.0a11, <max> was stripped as a requirement for the php dependency, breaking BC inside PEAR. However, this was a pretty minor break in the xml, and more of a break in PEAR itself. The change we are talking about would break every existing channel and all PECL releases containing a package.xml 2.0, so it needs to be a good reason. Thanks, Greg