Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:71481
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain adamharvey.name designates 209.85.223.174 as permitted sender)
MIME-Version: 1.0
Sender: adam@adamharvey.name
Date: Fri, 24 Jan 2014 14:34:14 +0800
Message-ID: <CADajX4AzUWh4-DALP_-fkpfPB+CMK4NvNJ2ByzmAUz2wGW8n4w@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Ruminations on PHP 5++
From: aharvey@php.net (Adam Harvey)

Internaleers!

We seem to have a few things being discussed at the moment that are
somewhat beyond the scope of the sorts of changes we've been adding
since 5.3. (I think the new release and voting processes have
generally worked well here, incidentally: 5.4 and 5.5 have both been
releases with a good range of new features, yet haven't caused
significant pain in terms of BC and have been pretty stable.) Things
that fall into that category for me include:

1. size_t and int changes.
2. Generics.
3. Function and method naming rationalisation (whether through
aliasing existing functions, or adding a new API through enabling
method calls on scalar variables).
4. Dare I say it, better multibyte encoding handling. (I don't want to
repeat the PHP 6 experience, but I'm also not sold on mbstring-ng
being the ultimate solution.)
5. Named arguments.
6. Unbundling of ext/mysql and removal of features deprecated in 5.4 and 5.=
5.

These all involve significant changes to writing PHP code and/or
extensions =E2=80=94 while some have no real BC implications, they are like=
ly
to change the best practice for writing and structuring PHP code.

So here's my question: should we be starting to lay out a rough
schedule and list of desired features for a new major release? (I'm
going to call it 5++, since the actual number is controversial; I'd
prefer 7, but I know there's a school of thought that 6 is usable
again. Whatever. We can bikeshed that down the track.)

Since I'm not usually shy about giving my opinion, here's how I think
we could do it:

Now until June 2014: test and release 5.6 as planned.
Post-5.6: branch a 5.x-master and use master for 5++.
Second half of 2014: RFC and vote on features both for 5.7 and 5++;
branch 5.7 at the appropriate time.
December 2014: 5.7.0 alpha 1.
First half of 2015: test and release 5.7 as per previous 5.x releases,
but also continue to RFC and vote on 5++ features.
June 2015: release 5.7.
Second half of 2015: feature freeze for 5++.
December 2015: release 5++.

This would allow us to stagger releases on each major branch: future
5.x releases (I'm assuming there would at least be a 5.8 in 2016)
would be mid-year, and 5++.x releases would come at the end of the
year. Effectively, no more than one branch would be in feature freeze
and QA at a time, hopefully avoiding a situation where php-src
developers are getting totally burned out trying to stabilise
different major versions at the same time. Eventually, of course, 5.x
would be phased out and 5++.x would be the only branch moving forward,
just as 5.x is today.

Am I talking complete bollocks? Should we get all of the
aforementioned features into future 5.x releases and not even consider
a new major? Is my schedule totally unrealistic?

Thanks,

Adam, who loves starting a good flame war on a Friday.