Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:72973
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.128.176 as permitted sender)
MIME-Version: 1.0
Sender: julienpauli@gmail.com
In-Reply-To: <1394067953.24706.30.camel@guybrush>
References: <CAMUwpuRkkaPHoFabtKA1ypfK6T_mDkGwtbMM3GRFaJPQBVDK3A@mail.gmail.com>
 <53176168.50305@lerdorf.com> <CAEZPtU5imvkn_Y=bhnW3S+mdeE+Bmku_YgaJ9u_32cQ4P1eKdQ@mail.gmail.com>
 <CAEra97qksqGyN4F8ebrdACQ-Mnt7y7xVhZ-FLj9JZf7GoDX-nA@mail.gmail.com> <1394067953.24706.30.camel@guybrush>
Date: Thu, 6 Mar 2014 11:53:26 +0100
Message-ID: <CAMUwpuSGDdT9F3xj-=c01E_ugriL7YkxErekLZkP91ezZ=hMkg@mail.gmail.com>
To: =?ISO-8859-1?Q?Johannes_Schl=FCter?= <johannes@schlueters.de>
Cc: Maxime Veber <nek.dev@gmail.com>, Pierre Joye <pierre.php@gmail.com>, 
	Rasmus Lerdorf <rasmus@lerdorf.com>, PHP Internals <internals@lists.php.net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] PHP6 thoughts about Engine changes
From: jpauli@php.net (Julien Pauli)

On Thu, Mar 6, 2014 at 2:05 AM, Johannes Schl=FCter
<johannes@schlueters.de> wrote:
> On Wed, 2014-03-05 at 21:59 +0100, Maxime Veber wrote:
>> Hello,
>>
>> I totally love the ideas about BC and cleaning everything. That's what P=
HP
>> need and deserve.
>
> I assume you are talking about userspae APIs, the often quoted needle vs
> haystack etc. If people think this is needed it is trivial to provide
> aliases and "fixed" versions for these from an extension (and/or
> userspace lib). As nobody has I assume that's more talk than need and
> people got accustomed easily.
>
>> Can you be more specific about what you want to change in "Cleanup API a=
nd
>> dead code" part ?
>
> The mail was about API implementation where there are grown APIs where
> parts might not be needed anymore.
>
>> And na na, it's not only for an hypotetic php7 version. We change things=
 or
>> we do not change !
>> After all, php move great with minor releases... !
>
> There are two requirements
>
>       * people who do
>       * thought about backwards compatibility
>
> The first item is hard, the number of people actually doing cleanup
> tasks is a small fraction of our relatively small contributor base. So
> going by Julien's list, the expected timeframe and the available work
> power doing all those things is almost impossible.
>
> Secondly, breaking too much at once is not an option. "Compatibility is
> a feature". for one there is lots of legacy code and knowledge, secondly
> it tells users that they can invest in PHP and won't get too much update
> pain later. See also the "success" of either Python 3 or Perl 6 which
> "fixed" too many things giving them low adoption. This by no means we
> shouldn't fix and improve things but that's a continuous process. (my
> favorite example: register_globals took literally 10 years from us
> starting to promote alternatives till we removed the option)
>
>
>> If we want to change, let's to what have to be done *now* !
>
> We are in constant change. There is barely a language as commonly used
> as PHP which changes so rapidly.
>
> johannes

Huh, yes, sure, my ideas are a little bit big in dev time, I fully
understand this.

However, they are written now :-)

I fully agree with Johannes and Rasmus by saying that if we break too
many things at the same time, we're never gonna reach our objectives
and this will lead to another failure from us. Unacceptable.
We should take the big cake part by part. Our release process
https://wiki.php.net/rfc/releaseprocess allows us to break BC in ABI
and internal API in minor releases. So we could have a PHP6.0 with
some ideas, 6.1 with another one, 6.2 again, etc... knowing that we
cannot break BC in external API (PHP userland), we then should
concentrate our thoughts on this critical point now.

There is one year gap between every minor, which is just enough (IMO)
to add a new "big" internal feature.
Once more, I'm talking about INTERNAL changes here. We can make those
happen into minors (according to our release process), like we did in
5.4, massively changing the VM compared to 5.3.
PHP6.0 should prepare the code base for future 6.1, 6.2, 6.3 etc...
each one adding another *internal* feature. External API would already
have been prepared/designed in 6.0.

So we have to concentrate on "what features do we want in PHP API
(external one) for the to-be-long 6.X series" right now. Because
after, we won't be able to change the PHP userland API anymore.

I'am also one of the guy thinking that we have to narrow our
timeframes for majors. Majors are about breaking external API, for PHP
users. 10 years is too big, something like 5 years seems more
reasonable.

We also have to master our communication. We all remember PHP4 to PHP5
pain, at this time, but things have changed.
PHP is nowadays much more professionnal, and our distros maintainers
are doing a much better job than 10 or even 5 years ago.

We should not be taken as responsable for the slowness of upgrading
PHP worldwide, but we should always think about easing it.

So to sum things up, I'm not against moving slowly but safely, that's
the way to move.
We have a clear view of our release process, one minor per year where
we are allowed to break internals and refactor internals and add new
internals stuff, one rev per month for bug fixes, and one major every
{{- we don't know but 5 years seems like right, why not vote this part
all together? -}}


Julien.Pauli