Re: Is the "No BC Breaks in Minor Releases" policy enforceable?

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]