> -----Original Message----- > From: Rowan Collins [mailto:rowan.coll...@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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
