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 

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 

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 

But again, I really do hope that we can however wrap up the debate up by end of 

Lukas Kahwe Smith

[1] http://wiki.php.net/rfc?do=register
[2] http://wiki.php.net/todo/php60

PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to