On 2010-03-14, Lukas Kahwe Smith <m...@pooteeweet.org> wrote: > 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. +1. RFCs still seem to be a good way to work out new features while we still need to improve the way we handle it and particularly make developers who already have an account still write RFCs (and create an experimental branch) instead of committing directly to trunk.
> 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 agree that we should try to get releases out more regularly, also we should still have a little bit of flexibiltiy (particularly in the first releases). I hope we can reduce some of the issues that we had with 5.3. > 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. Yes experimental branching shouldn't be a problem. I persoanlly would prefer if we just create php-src/experimental/ or php-src/developer/<name>/<branch> for this purpuse to not clutter branches/ with a million names. > But again, I really do hope that we can however wrap up the debate up by end > of April. David -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
