Re: 8.0 is not 10 years away

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]