Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:47273
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Date: Sun, 14 Mar 2010 11:58:57 -0500
To: internals@lists.php.net
References: <36D0BC9D-72BA-4087-9088-A054F0E82A52@pooteeweet.org>
User-Agent: slrn/0.9.9p1 (SunOS)
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <slrnhpq56m.oq2.sn_@experimentalworks.net>
Subject: Re: moving forward
From: sn_@gmx.net (David Soria Parra)

On 2010-03-14, Lukas Kahwe Smith <mls@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.
>
 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