I have to back Sebastian with what he said. Obviously the release methodology currently applied does NOT work, neither for the project nor the community around it.
Do it how ever you like - discuss whether it's legal to add new features on HEAD only or on release branches like Jani said.
BUT: Once you agree the work is done on a branch and you make something available that has a RC in it's version name, it's GAME OVER. No more features. Only bugfixes.
That is the only way for ppl to make sure there will be no unnecessary and unexpected changes anymore. Once my software passes tests with an RC, I can assume in good faith that it's very unlikely to break again.
You cannot expect folks to re-test everything with every new RC, and so it's not PEAR's fault if they were not the first to notice the problems.
Remember the discussion about curlies? I also never understood why that had to be tackled in an RC5.
Should you find out late in this process a feature has been forgotten (i.e. #ifdef'd out) and you all agree that it has to go in - abort the RC phase, put it in again, restart (maybe with another RC name) to make ppl clear that they do need to re-test.
If you're kind, assert that there will be a certain time between RCs and releases, or communicate with your major community projects out there to make sure they do their work or do whatever.
But there is just a single simple basic rule that needs to be adhered to - that's all Sebastian pointed out.
-mp.
-----Ursprüngliche Nachricht-----
Von: Ilia Alshanetsky [mailto:ilia@prohost.org]
Gesendet: Samstag, 26. November 2005 16:49
An: Sebastian Bergmann
Cc: internals@lists.php.net
Betreff: Re: [PHP-DEV] Re: PHP 5.1 (Or How to break tousands
of apps out there)No one project follows the same release methodoly, everyone
uses what works for them and the community around the project.Ilia
Matthias Pigulla wrote:
I have to back Sebastian with what he said. Obviously the release methodology currently applied does NOT work, neither for the project nor the community around it.
It has worked for many years, just because of one problem you don't
scrap the process.
BUT: Once you agree the work is done on a branch and you make something available that has a RC in it's version name, it's GAME OVER. No more features. Only bugfixes.
RCs are there for testing, if you don't test them don't complain when
things break. The main reason for RCs is to spot critical bugs and
important regressions. Some of those are test suit can pickup, but most
issues are discovered through "real" usage.
You cannot expect folks to re-test everything with every new RC, and so it's not PEAR's fault if they were not the first to notice the problems.
That is exactly what's expected.
Remember the discussion about curlies? I also never understood why that had to be tackled in an RC5.
They were removed.
Ilia
Ilia,
I do not agree with this. Since there should be only bugfixes in RC
I should only test to see if the known problems are gone and there are
no regressions. Check if the NEW classe/function clashes with mine's
or PEAR's not!
You cannot expect folks to re-test everything with every new RC, and so it's not PEAR's fault if they were not the first to notice the problems.
That is exactly what's expected.
mbneto wrote:
Ilia,
I do not agree with this. Since there should be only bugfixes in RC
I should only test to see if the known problems are gone and there are
no regressions. Check if the NEW classe/function clashes with mine's
or PEAR's not!
Some bug fixes may cause regressions in behavior, which is why every RC
needs to be tested.
Ilia