Wez Furlong has a look today on his blog at the inside of "release engineering" - the process of creating and packaging software for release.

One of the things I spend a lot of time doing is release engineering. If you're not familiar with the term, it's the process of taking some software product and packaging it. Piece of cake? Far from it.

The packaging has to be perfect. It needs to handle all kinds of quirky problems on the different flavours of systems that you're planning to install on. You need to expect the unexpected (you have no idea exactly what people have done to their systems), handle all errors gracefully, preserve everything that might be important, and at the end of the day, it just needs to work.

So, why have I been going on about all this? The recent (or not so recent) changes in the PEAR infrastructure have introduced a new package2.xml file to describe packages. For reasons of backwards compatibility, the older package.xml file still needs to be maintained. This instantly makes the release engineering section of my brain nervous...

He's asking abround about a better alternative to mainting twice the amount of data for the future, figuring that there has to be a way to automate around the package2.xml file to create the older package.xml file needed by PEAR...

There is no good reason why we can't provide an auto-generated package.xml file, especially if the package2.xml describes the same package as the package.xml file.

Why can't we make things easier instead of harder?