Hi,
Here is a list of ideas I have to improve the release management
process. Once I will get back to Berlin tomorrow I will try to put some
of these into action.
1) Select a list of popular PHP applications (in total about 3-4 ..
things like Gallery, MediaWiki ..) and make sure they test RC releases.
Maybe my giving them an ego-padding status. This would essentially
expand our unit testing to also include some more real world code. As
the PHP 5.0.5 release highlighted, currently this is not done.
2) Provide advance notice of upcoming releases that are likely to break
code (usually this should just happen in cases where we make the
language more strict in dealing with broken code). This would also help
projects to better adapt to forthcoming releases and should also get us
more RC testing. These advance notices should be limited to releases
where we forsee larger challenges (like in PHP 4.4, maybe even for 5.1
SPL changes ..).
3) Maintain a todo list for the maintainer in CVS or in some wiki, so
that developers do not forget things, but more importantly that the RM's
have a better overview. I presume most RM's already maintained such a
list on their end, but they might just mis something and so it would
make sense to make this list public.
4) Add a "README.RM" that lists some guidelines like RC naming, what
projects to contact for RC testing etc.
I would appreciate comments on this, but I will try to make atleast 3) a
reality on my personal wiki if needed. Though without the help of
internals I will probably only be able to provide an incomplete list at
best.
regards,
Lukas
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
