Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:77975
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 209.85.220.170 as permitted sender)
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>
In-Reply-To: <543D1743.5070108@gmail.com>
MIME-Version: 1.0
Thread-Index: AQJhOtFYbNxiWbIyui1Tg5SfejmcmgFbpkdLAYALC18CAXxecQLgMa7oAgAZ/IECScYx9JqsqnLQ
Date: Tue, 14 Oct 2014 15:59:41 +0300
Message-ID: <d6290ec3f02115fac38541a04e4f252c@mail.gmail.com>
To: Rowan Collins <rowan.collins@gmail.com>, internals@lists.php.net
Content-Type: text/plain; charset=UTF-8
Subject: RE: [PHP-DEV] RFC: PHP 7.0 timeline
From: zeev@zend.com (Zeev Suraski)

> -----Original Message-----
> From: Rowan Collins [mailto:rowan.collins@gmail.com]
> Sent: Tuesday, October 14, 2014 3:30 PM
> To: internals@lists.php.net
> Subject: Re: [PHP-DEV] RFC: PHP 7.0 timeline
>
> Jonny Stirling wrote (on 14/10/2014):
> > At the same time, which I think has been discussed before, perhaps
> > it's time for a regular major release cycle (regular as in x (2-3?)
> > years) so that there is a timescale for when new changes (or ones that
> > might be intentionally or unintentionally missed / skipped for this
> > major) that wouldn't be allowed in minor releases can be proposed /
> > written against?
> >
> > Apologies for strictly being off-topic.
>
> I actually think this is very much to the point. People keep saying "we
> can
> always do it in 7.1", but that implies that we could already have done it
> in 5.6
> - i.e. it doesn't need a major version bump.

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.

> So, if we keep the timeline for 7.0 short, it would be nice to have at
> least
> tentative plan for how long before 8.0 - be it 3, 4, or 5 years.
> That would give some hope for the features that don't make it into 7.0 not
> being completely forgotten, and hopefully relieve the pressure to get it
> completely right this time.
>
> As has been pointed out before, a clear timeline for major releases would
> also allow much stricter enforcement of what is allowed in minor releases.
> 7.1 and 7.2 could be true minors, knowing that 8.0 was just around the
> corner with all the juicy bits in it.

I think the 'juicy bits' comment suggests a possible misconception about
what major versions are, at least in their current definition.  We can push
*any* type of juicy feature into a minor release, as long as it doesn't
break compatibility.  We've introduced plenty of new features in the 5.x
family, including after we changed to the stricter rules on what can and
cannot make it into a minor version.  We needed 7.0 because phpng, AST and
uniform variable syntax all break compatibility, although thankfully none of
them does it in a very significant manner.  Also, historically major
versions also tended to bring performance improvements and substantial
engine refactoring.  But still, new features, including fairly major ones
can make it into 7.x, exactly like they made it into 5.4/5.5/5.6.

Zeev