major new feature for pearweb: roadmap support
| From: | Gregory Beaver | Date: | Sat, 17 Feb 2007 23:42:26 +0000 |
| Subject: | major new feature for pearweb: roadmap support | ||
| Groups: | php.pear.dev | ||
| Request: | Send a blank email to pear-dev+get-45664@lists.php.net to get a copy of this message | ||
Hi all,
I finally sat down and implemented roadmap support for pearweb. I
basically cut/pasted the effort put into Chiara_Bugs by me a while
back. One of the amazing facts of this cut/paste was the design of
Chiara_Bugs made it extremely easy to port the code to pearweb. This is
definitely the direction that pearweb needs to go: separating logic from
display, and abstracting sql to dataobjects as much as possible.
I've released pearweb 1.5.0RC1 so that I can get some feedback.
Everyone who has been testing pearweb, would you please:
pear up pearweb-beta
and verify that you can successfully create roadmap items? You'll need
to update your database, the two new tables are in sql/bugs.sql, but if
you run the post-install script:
pear run-scripts pearweb
it will try to update the database for you. This is only a convenience
for testing, if the script doesn't work, it won't affect the live
server, all updates are done by hand to ensure success.
Here's how the new feature was implemented:
There is a new link on each package's home page in the "releases"
section to the development road map. As a developer, it is your job to
define the roadmap. A roadmap is simply a future version number and a
brief description of what you hope to accomplish, plus an anticipated
release date.
What makes it really useful is you can assign existing bugs and feature
requests to any roadmap versions, so that it is possible to track the
progress of a release. In addition, a record exists of bugs fixed and
features implemented that can easily be used to generate a changelog
(not implemented yet). The assignment of bugs happens when editing a
bug as a developer. In this case, you can click on the roadmap versions
that the bug will be fixed in, or the versions that a feature will be
fixed in.
Using this system, it will make it quite easy to define the goals and
even the release schedule of a package. This can be used to recruit
developers either to do specific tasks or to help coordinate many
developers.
Because the feature is so important, I would like as much feedback as
possible before going with a stable release of pearweb that will go live
at pear.php.net.
Thanks,
Greg