On Tue, Dec 16, 2014 at 8:55 PM, Florian Margaine <flor...@margaine.com> wrote: > > Hi list, > > I think having a minor PHP version for the only sake of adding E_DEPRECATED > is kind of pointless to be honest. Historically, PHP (or other languages > for the matter, I'm thinking of python) minor versions have brought new > features. Adding notices is not a reason for a new version imho. >
please be aware the not everybody agrees on the no new features rule, but from as I can tell most people seem to agree that no new major features should be included. in an ideal world those kind of E_DEPRECATED messages would be there already before we break or remove a function so there would be no reason for this discussion. because this isn't a case I think it is reasonable to have a discussion if it would worth to have another minor in the 5.x series to make the upgrading to 7.0 easier. my proposal was to stop adding minor features into 5.6, create an 5.7 where those can go and make sure that any(which is possible/feasible) BC break will be foretold via E_DEPRECATED. > > If what we want are notices, and helping people to migrate to PHP 7, then > we can create tools for this. For example, python made a tool to help with > the transition of python 2 to python 3. Go did the same for 0.x to 1.0, if > my memory serves right. The point of new versions is to include new > features or bug fixes for the language, static analysis can be done with > external tools. > This is not the first time this idea came up, and some of the BC incompatible changes in PHP7 already have such tools to spot such usages or fix them automagically. > > The fact that we'll have to maintain one more version is also not something > to be taken lightly, especially when I see examples of how things progress > in php-src. (I'm thinking about the recent contributor who gave up.) > I think it would be a bit more work, but not that much: 5.4 would stay in security fix mod until 5.7 is released, 5.5 and 5.6 would be put/kept in bugfix/security fix mode, new features would only target 5.7 and 7.0. Merging would be one step longer (for another year) in worst case scenario (bugfix or security fix) but even that would be less of a PITA if not for NEWS. (About the recent contributor gave up stuff: I think that is more of a problem when the policies/processes are not explicit and/or abused.) > > Now, if the reason people want PHP 5.7 is to extend PHP 5 lifetime, then > it's another matter, and the lifetime of existing versions could be > extended. > That's one reason, which doesn't really require us to do anything, as we have plenty of time to realize if we want to/have to prolong the lifecycle of PHP5, and doesn't take much than updating http://php.net/supported-versions.php and bribing the RMs to cover another year with the RM stuff. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
