Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:77982
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain jonstirling.co.uk from 209.85.212.177 cause and error)
Message-ID: <543D236B.2000308@jonstirling.co.uk>
Date: Tue, 14 Oct 2014 14:21:47 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2
MIME-Version: 1.0
To: internals@lists.php.net
References: <32b8315ede38cd03ad4a7ab4497397e9@mail.gmail.com> <CABBJUpc0T5_bcq+r3DNGyFLhkSdFV-acHzi5nmKWRiW5_vJiYA@mail.gmail.com> <CAMUwpuSd7Ojhrn4yh53iWzukztqo=jnH9zRnCi1HXRtLRTWkBg@mail.gmail.com> <af333ee84905e4391ff0bfdf2b30c5e2@mail.gmail.com> <CAMUwpuQdRTfxogKYaNP0adFV_7QOOsOHgaUD4PZDMSq1dnF2+w@mail.gmail.com> <543CF595.6030107@jonstirling.co.uk> <543D1743.5070108@gmail.com> <d6290ec3f02115fac38541a04e4f252c@mail.gmail.com>
In-Reply-To: <d6290ec3f02115fac38541a04e4f252c@mail.gmail.com>
Content-Type: multipart/alternative;
 boundary="------------040403010401020101080905"
Subject: Re: [PHP-DEV] RFC: PHP 7.0 timeline
From: phoenix@jonstirling.co.uk (Jonny Stirling)

--------------040403010401020101080905
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit


On 14/10/14 13:59, Zeev Suraski wrote:
> That depends on the feature in question.  The only features/changes that
> simply cannot make it into non-major releases are ones that break
> compatibility.  Ideally there shouldn't be too many of those, regardless of
> our release timeline - to make the lives of our users easier.
>
>> What we should really be saying
>> is "we can always do it in 8.0", but I suspect people are wary of saying
>> that
>> because it feels such a long way away.
> We should try to push most of those into 7.0.  We shouldn't release 7.0 with
> a long list of changes that we think should make it into 8.0.  Instead, if
> we know about a change that requires a major version change - we should
> review it now, and decide for/against it.  It's the
> non-compatibility-breaking-changes that we can safely say can wait for 7.1,
> because they can.
>
Hi Zeev,

You are of course correct, a lot of changes can be made to minor 
versions and have been in the past that don't require a major. That 
doesn't change that there may be things missed (there may not, that's 
not the point), or ideas that come up after GA or even at the last 
minute e.g. in RCs or whatever that are wanted but have missed the 7 
boat. Sure, get as much in as reasonably possible, but you potentially 
can't get everything that comes up and you definitely can't get anything 
that comes after release that requires a major. Some people may even be 
keeping stuff back as you've provided a currently expected set of 
changes. Nothing wrong with any of this, all is good.

If there is a cycle in place and thus an expected timeline / process for 
*after* PHP7, then that surely makes the PHP7 timeline simpler to 
manage, it gives a milestone for new ideas to be worked against and 
more. If a good idea came through an RFC, but couldn't be done for PHP7, 
the RFC would be dropped as there is nothing currently beyond that.

Tl;dr my thoughts are about after PHP7, which is itself looking pretty 
good. I just don't want for the community, or the awesome internals devs 
with great ideas walking away from things because there is no future plan.

Again, apologies for the side-track. It's not really specific to the 
thread, but I still feel it's an important point.

Ta.
Jonny.

--------------040403010401020101080905--