results of work
| From: | Greg Beaver | Date: | Fri, 23 Sep 2005 05:57:43 +0000 |
| Subject: | results of work | ||
| Groups: | php.pecl.dev | ||
| Request: | Send a blank email to pecl-dev+get-2963@lists.php.net to get a copy of this message | ||
Hi Wez and peclers,
I just spent about 3 hours going through every pecl extension's
package.xml and running pear convert/pear package.
I was somewhat surprised at the number of invalid package.xml files in
there. I added a ton of validation to package.xml 1.0 stuff - there are
some serious problems that have been present in every PEAR version, like
allowing PHP dependencies that just don't work, and so on.
Lots of people are using role="source" instead of role="src". I saw a
few packages with no lead developer, and 3 with invalid xml altogether.
I assume those 3 are siberia candidates :). In any case, those of you
reading this: grab PEAR 1.4.1 when it is released. For those of you
wondering, PEAR 1.4.1 will have a HUGE number of fixes for PECL found in
rigorous testing. It will be released just as soon as a rapid QA
process has gone through.
So, after all of this, I can honestly say that pear convert/pear package
combination works on every single pecl package that has a valid
package.xml 1.0. This is a good first step. Here is a release process
flow I would like to run by you:
1)
$ pear package --convert
This would automatically run "pear convert" as if the user had typed the
command, and then run "pear package"
2)
$ cvs add package2.xml
$ cvs commit -m "initial commit"
3) This is the important part: if it is the first time ever that a
conversion has been run, the package2.xml must be checked for the following:
- is the package name the exact case-sensitive extension name?
- does the thing build and compile?
If those answers are both yes, then auto-conversion will work.
Otherwise, it will not work, and I will need to either tweak the
installer so that it will work, or figure something out.
So, basically, the important difference here is that package2.xml will
still be present in the repository, which means it can still be tagged
and brought back to re-create a release for whatever reason. This also
still keeps the human element necessary to catch bugs, while providing
ease. Once the package.xml is present, you can update with this workflow:
<hand-edit package.xml>
$ pear convert
$ cvs commit -m "whatever"
Comments?
Greg