> -----Original Message----- > From: julienpa...@gmail.com [mailto:julienpa...@gmail.com] On Behalf Of > Julien Pauli > Sent: Tuesday, December 16, 2014 11:00 PM > To: Florian Margaine > Cc: Rowan Collins; PHP Internals > Subject: Re: [PHP-DEV] [RFC] PHP 5.7 > > - We cannot patch 5.6 to add any Warnings-of-any-kind (stable release, > under release process that forbids that)
What part of the release process forbids that? I don't see that anywhere in there, at least not any more than it forbids such deprecation messages in a minor (2nd digit) version. New features are the only (relevant) difference between minor and bugfix versions, and I don't think anybody considers deprecation messages as new features. They are, in practice, very minor compatibility breakages - and in that sense, technically, both bugfix (3rd digit) and minor (2nd digit) versions forbid those equally. Also note that the release process isn't exactly a flawless document that predicted all the scenarios we're facing (and are going to face) in the future. Its focus was bugfix and minor releases, and consequently, not much thought was made regarding migration issues of the sorts we're discussing today, towards a major version. If we reach the conclusion (and it's clearly an if), it's not the release process that should stop us. > - Rolling out a 5.7 with *just* Warnings-of-any-kind is silly, see the > topic I > just replied to which is valid to me Agreed. > - Rolling out a 5.7 with Warnings-of-any-kind + some little-or-not new > features cancels point number one > > What else ? Do nothing is still (IMHO) the most sensible option IMHO. We're not seeing major compatibility breakages in 7.0 (at least not at this time), to the level that upgrading through some middle version is really all that necessary. Considering the adoption levels of 5.6, 5.5 and even 5.4, we can expect that most people migrating to PHP 7 will not be doing it from one of the latest PHP 5.x versions, but older ones, rendering all of these options useless. The one option that could be relevant to these scenarios is a separate analysis tool, but it's much more difficult to pull off, and I don't think the level of breakage (as it appears right now) justifies the effort. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
