moving forward

Hi, I would like to ask everyone that wants to see some new feature in the next bigger PHP update to create an RFC on the wiki. I have to check why the register link [1] disappeared from the login page (anyone with a php.net svn account can just login without registering). Ideally we will simply cherry pick the features for the next release from the old todo list [2] as well as mature RFC's. Personally I also think that we should make sure that we do not spend months in this planning stage. If we do not yet feel ready to do the big leap to a new major version number, since we cannot play the "lets drop some BC" card in every release, then we can of course just bump the minor version number for the next release. Even if we do not solve unicode with the next release we already have plenty of good proposals on the table. But focusing development again on a single branch and the willingness to review our approach to unicode I think we can move forward again either way. So I am suggesting that we should aim to have a solid release plan (schedule and feature set) done no later than end of April. Personally I would like us to be able to look towards the first alpha for this new version in Q4 2010 or Q1 2011, but that is of course something that is up for debate. Obviously if we give ourselves a more or less specific timeframe it also limits the number of features we can deliver. But I think we should really become a bit more disciplined in this regard and maybe even work towards a semi regular cycle for new releases. I really like how PostgreSQL is doing things in this regard. Of course they still slip the dates at times, but so it goes (but they do not slip a few years .. just a couple of months). The important bit is that with regular releases contributors feel more like they will actually see the solution to their "itch scratching" released before they move on to other "itched to scratch". It also means that if a feature doesnt make it into the release plan for the next release, developers will at least have a rough idea for the timeframe when they will have another chance to get a given feature into PHP. Plus it will make it easier for others (like distributions and app developers) to work with us. Most importantly it will spare us running into the situation we had with PHP 6 and 5.3 in the future where because we had time finishing up something we just end up piling features up for years making the release process a nightmare. I would also like to bring up another point. Since we are now on SVN (and there are nice bridges to DVCS for those that want to use them), we can now also more easily enable developers to work on complex or risky features in a branch instead of trunk. So for example if we feel like it will take us too long to come up with a unicode plan, then I would suggest to leave it out the next release and simply have the people that have an idea for an approach create a branch and work things out there. This way normal development in trunk can commence. But again, I really do hope that we can however wrap up the debate up by end of April. regards, Lukas Kahwe Smith mls@pooteeweet.org [1] http://wiki.php.net/rfc?do=register [2] http://wiki.php.net/todo/php60