Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:47522
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 212.25.124.185 as permitted sender)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 23 Mar 2010 15:04:04 -0700
Message-ID: <698DE66518E7CA45812BD18E807866CE03F16456@us-ex1.zend.net>
In-Reply-To: <alpine.DEB.2.00.1003231550080.4153@kossu.derickrethans.nl>
Thread-Topic: [PHP-DEV] trunk is alive and open
Thread-index: AcrKorV0l7YL2jkpREKZlYnJOt0plwAMB/tA
References: <alpine.DEB.2.00.1003231550080.4153@kossu.derickrethans.nl>
To: "PHP Developers Mailing List" <internals@lists.php.net>
Subject: RE: [PHP-DEV] trunk is alive and open
From: andi@zend.com ("Andi Gutmans")

> -----Original Message-----
> From: Derick Rethans [mailto:derick@php.net]
> Sent: Tuesday, March 23, 2010 9:05 AM
> To: PHP Developers Mailing List
> Subject: [PHP-DEV] trunk is alive and open
>=20
> Hello,
>=20
> I've just created trunk for 5.3 again. I've set the version to
5.3.99-dev as to
> explicitly not decide on whether there will be 5.4 or
> 6.0 next.
>=20
> New features should go to trunk; but anything other then trivial
additions
> should require an RFC and discussion. I think Antony has the FPM RFC
ready
> to show what sort of stuff would be useful to have. I'll let Antony
start a
> thread to discuss it (although I doubt there needs to be a lot of
discussion for
> it).
>=20
> I think Ilia mentioned that he wanted to do one more normal 5.2
release,
> after which it will be "security fix only". So for now my suggestion
would be:
>=20
> - new features to to trunk
> - bug fixes go to 5.2 and 5.3.
>=20
> Let's see what cool stuff we can come up with for the next version!

What about defining a release manager for the next release? I think that
is an important aspect of moving things forward. I also thought the dual
RM in PHP 5.3 worked quite well although it is not necessarily a must.=20
=09
I do think we want to avoid ending up with another stale trunk. As I
mentioned in my previous note it's important to have a reasonable scope
for the next upcoming major (5.4/6.0) release and make sure we do have
the right amount of discussions re: new functionality committed. So I do
propose that in the coming weeks (as 80% of the ideas surface) the RMs
create a roadmap for the next version which clearly identifies the
must-haves and should-haves. This can always be changed/tweaked (as we
always have in the past) but it sets the tone for pushing out
functionality sooner rather than later (i.e. if a should-have is still
not quite fully baked but all must-haves are done then ship).=20

As we saw with PHP 5.3 it ended up being a pretty major version and it
delivers a lot of incremental value. So it was good it didn't wait for
every single idea.

Andi