Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:47262
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain pooteeweet.org from 188.40.37.16 cause and error)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Date: Sun, 14 Mar 2010 13:48:04 +0100
Message-ID: <36D0BC9D-72BA-4087-9088-A054F0E82A52@pooteeweet.org>
To: PHP Developers Mailing List <internals@lists.php.net>
Mime-Version: 1.0 (Apple Message framework v1077)
Subject: moving forward
From: mls@pooteeweet.org (Lukas Kahwe Smith)

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=3Dregister
[2] http://wiki.php.net/todo/php60