AW: Re: PHP 5.1 (Or How to break tousands of apps out there)

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.