Hi Kalle! On 19.11.2016 at 19:35, Kalle Sommer Nielsen wrote:
> 2016-11-19 19:23 GMT+01:00 Christoph M. Becker <cmbecke...@gmx.de>: > >> IMHO, we should consider introducing a fixed schedule for major releases >> (say, every 4 years). > > I think that should depend on a case by case basis for when we are > working towards a new version, a lot of awesome work are already in > for master that won't be out for at least another year. At the point > when we pick RMs for the next branch, then we have in the past > evaluated the scope of changes currently planned to be included, what > is currently in and what the magical guys at Zend are doing and decide > there. Having a fixed, forced major version does not sound that great > if we do not have something awesome that could only ever exist in a > new major version, But this short-dated decision on whether next will be a major or minor is exactly the problem. Consider, for instance, this RFC which targets 7.2 for deprecation and 8.0 for removal. What if we decide in some month that there'll be no 7.2, but rather 8.0 will be next? Would we remove the features without a deprecation phase, or would we deprecate them for 8.0 and remove later? Either way, I'm pretty sure that we would have a lenghty discussion, and might even need another vote. And at least some RFCs and documentation would have to be fixed. At the very least I would suggest to decide whether the next version but one will be major or minor at the same time we tag the first alpha of the next version. I.e. this decision would had been made months ago, and actually all RFCs I've read assume that PHP 7.2 will be next. -- Christoph M. Becker -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
