Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:93987
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.44 as permitted sender)
To: PHP Internals <internals@lists.php.net>
References: <6c03dafd-093a-0087-6312-96fede93c5f0@gmail.com>
 <BY2PR0201MB17843F26C4E02181DDDED285BF540@BY2PR0201MB1784.namprd02.prod.outlook.com>
Message-ID: <76d6d168-6759-816c-5dfa-fbe56bb3f011@gmail.com>
Date: Wed, 15 Jun 2016 00:10:27 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101
 Thunderbird/45.1.1
MIME-Version: 1.0
In-Reply-To: <BY2PR0201MB17843F26C4E02181DDDED285BF540@BY2PR0201MB1784.namprd02.prod.outlook.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Is the "No BC Breaks in Minor Releases" policy
 enforceable?
From: rowan.collins@gmail.com (Rowan Collins)

On 14/06/2016 11:43, Dmitry Stogov wrote:
 > Just take into account, that 7.0 was released more than after 10 years
 > of php-5 life, and of course we don't have any plans or goal for 8.0 yet.
 >
 > Waiting another 10 years for fixing inconsistencies, that we "missed" in
 > 7.0, would limit our progress on bytecode and VM optimizations targeted
 > to 7.1 and future progress in next minor versions.

I'm certainly not talking about waiting 10 years. If anything, I'm in 
favour of making breaking changes *sooner*, as long as we label them 
properly.

Firstly, the historical release cycle for PHP major versions is 4-5 
years, not 10; 5.x was an anomaly, but if you treat 5.3 or 5.4 as 
stand-in for 6.0 (which in many ways they were) the cycle is pretty 
consistent. So an 8.0 in 2019 or 2020 would fit the historical trend 
perfectly. Secondly, there's no reason we need to be tied to that 
history; we could say that from now on, every 3 years will be a new 
major, or even every other release (a "tick tock" cycle of innovate and 
stabilise).

If we wanted to, we could even scrap the notion of "minor" and "major" 
releases, and, since we have one release a year, call them 2016.0, 
2017.0, etc. Assuming we don't want to do that, there's presumably some 
distinction in people's minds of what a major release means, and I guess 
I'm trying to find out what that is.

Another way to look at it is to say "given the set of changes we have 
for this release, what version number should we give it?" It sounds like 
in your mind, a release would have to be something more than that to be 
"worthy" of the 8.0 label; some grand plan, etc. In that case, maybe the 
BC rule isn't really relevant, because we're "in the PHP 7 era", 
regardless of what changes we're releasing?

(Note: I've deliberately tried to keep this thread about the policy in 
general; for my concerns about this change in particular, see the other 
thread.)

Regards,
-- 
Rowan Collins
[IMSoP]