Home > Archive > PHP PEAR Questions and Answers > July 2006 > Criteria for stable release
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Criteria for stable release
|
|
| James Stewart 2006-07-12, 6:58 pm |
| I've had a number of users tell me they're finding XML_Feed_Parser to
be stable in their day to day use and ask if I can move it to a
stable release.
I have a few to do items I want to deal with before that, but other
than those I'm not sure if there is a particular process I need to
follow to bring the package to a stable release? Does it need to be
reviewed, or can I just mark it as stable when I'm ready? I'd like to
get a release candidate ready within the next ten days.
James.
| |
| Greg Beaver 2006-07-12, 6:58 pm |
| James Stewart wrote:
> I've had a number of users tell me they're finding XML_Feed_Parser to
> be stable in their day to day use and ask if I can move it to a stable
> release.
>
> I have a few to do items I want to deal with before that, but other
> than those I'm not sure if there is a particular process I need to
> follow to bring the package to a stable release? Does it need to be
> reviewed, or can I just mark it as stable when I'm ready? I'd like to
> get a release candidate ready within the next ten days.
A stable release ideally should have:
1) end-user documentation in docbook format which is used to generate
the manual at pear.php.net
2) in-code /** documentation */
3) regression tests in one of the 3 popular formats:
- PHPUnit1/2/3
- SimpleTest
- .phpt
A package as simple as XML_Feed_Parser (input is discrete and easily
simulated) should definitely have regression tests to test for expected
behavior, bounds, and error conditions. This is a royal pain, but if
PEAR can have them (and 600+) then I think you'll be fine :)
By the way, thank you for asking, it will definitely remedy any future
problems.
Greg
|
|
|
|
|