Hi! > An alternative would be just putting a few #if 0 in code > (phpdbg_out.c where the outputting of anything is centralized) to > make XML stuff not usable. Maybe that one is the cleanest and least > invasive with still allowing us to change the whole XML stuff. And at > the same time the normal improvements would still go into 5.6.3?
Hot-patching with if-0's is not how things should be done in stable branch. If the code is not ready for prime time - which is obviously the case here - it should be developed - and tested! - in the feature branch. Then merged to master. And only then, after proving working - wait for it - put to discussion on internals about getting it into stable branch. Dumping it into a stable branch and hoping "maybe we get lucky and can get it into the next release" is not how release management should be done. Stable branch is called "stable" for a reason. This is not something critical that we have to release ASAP or the world burns. It's not a security fix. It's not even a critical feature millions asked for for years and this is the only chance to get it in. There is absolutely enough time to do it right. So let's do it right. >> To add for 3.: Issues where with what I really couldn’t think of >> (separate build dir on Linux…) or the issues with a JSON dep or >> Windows which I couldn’t test. And that's exactly the point. It's not your failure. It's nobody's failure. That's how the software world works - you can not foresee everything. You have to test. That's why we do not start with merging into the stable branch a day before the RC. It's not because somebody's code is particularly bad. It's because the release practices are the result of experience - if you don't do it, you *will* have trouble about which you had no way of knowing. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
