Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:80929
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.53 as permitted sender)
Message-ID: <54BF8A2D.7040702@gmail.com>
Date: Wed, 21 Jan 2015 11:14:53 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: PHP Internals <internals@lists.php.net>
References: <54BEC837.5030302@gmail.com> <54BEE357.6060508@b1-systems.de>
In-Reply-To: <54BEE357.6060508@b1-systems.de>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] 8.0 is not 10 years away
From: rowan.collins@gmail.com (Rowan Collins)

Ralf Lang wrote on 20/01/2015 23:23:
> On 20.01.2015 22:27, Rowan Collins wrote:
>> Hi All!
>>
>> Occasionally, in various discussions, waiting for the next major release
>> is described as "maybe another 10 years", but I think that's a very
>> pessimistic prediction. It's more reasonable to expect it in half that
>> time, around 2020, and that is what we should base our decisions on.
>>
>> The 10 year figure for gap between major releases comes from a single
>> data point - the fact that 5.0 came out in 2004, and 7.0 will succeed it
>> in 2015.
>>
>> This leads to a worst case scenario, with annual releases, of 7.10 in
>> 2025, and 8.0 in 2026. If you count releases, not years, the current
>> process already shrinks that to end with 7.6 in 2021, 8.0 in 2022.
> You are very right,  but calculating with an experienced worst case +
> 20% is not a bad habit. PHP5 -> PHP7 isn't normal by itself.

Only where the worst case is due to external factors that might happen 
again. In this case, it was due to things we are absolutely able to 
avoid with the experience since then.

> One can
> hardly compare PHP5.0 and PHP5.4 and say it's the same release.

Agree; that's the core of my argument, that we are realistically 
following a 5 year cycle between majors.

>> So when deciding between rushing to add/remove something for 7.0 vs
>> waiting all the way until 8.0, remember to think in fives, not tens.
> That may be true, but remember "enterprise" distributions usually didn't
> do version upgrades in the past if not strictly forced by mainstream use
> cases. SLES 11 SP 2/3 broke this and added a PHP 5.3 and SLES 12 / RHEL
> 7 bring new policies, but they have already been released. The next
> chance for serious BC breaks to hit "enterprise" distributions might be
> 8-9 years at worst, even calculating with 5 years till the next major
> release.

Yes, that is worth bearing in mind. Of course, taken too literally, it 
also implies that any changes we make now won't "hit" for 3-4 years, so 
that we're always coding for some theoretical future use...

Still, for new features, knowing when you'll be able to rely on 
deploying them everywhere is important, so point taken.

-- 
Rowan Collins
[IMSoP]