implication of the new release process regarding of new versions (moved from "Proposal to deprecate create_function()")

On Fri, Oct 18, 2013 at 6:03 PM, Rowan Collins <rowan.collins@gmail.com> wrote: > On 18/10/2013 15:51, Ferenc Kovacs wrote: > >> shouldn't really happen if you strictly follow the "new" release process >> rfc was accepted: >> https://wiki.php.net/rfc/**releaseprocess<https://wiki..php.net/rfc/releaseprocess> >> , >> unfortunatelly it seems that there are some cases, when this can happen >> (some bug fixes, but the biggest offender was dropping deprecated features >> for 5.4.0 which were already removed in the 6.0 branch), but if you check >> out >> http://hu1.php.net/manual/en/**migration55.incompatible.php<http://hu1.php.net/manual/en/migration55.incompatible.php> >> you >> can see that the actual intentional BC breaks was really small, the only >> non bugfix BC break was removing the php logo urls, which was never meant >> to be a public api, but to be used by phpinfo(). >> > > Ah, I see. I guess it was the slew of changes in 5.3 and 5.4 which made it > seem like this wasn't the case, because they would collectively have been > 6.0. yeah, and don't forget that 5.3 was already released, and the 5.4 branch was already created before the new release process rfc got voted and accepted, so that was the main reason why those versions had more BC incompatible changes. > So the aim is that a script made to work on PHP 5.4 will now be guaranteed > to run on any version <6, although some required modules might have moved > to PECL? > yeah, the current rfc promises that, plus there are some case-by-case exceptions, mostly for bugfixing, plus it seems that introducing new reserved keywords/class/method/constant names is not a BC break(would be hard to introduce new features without that). > > As a user, it is certainly not obvious that features discussed as being > removed "soon" will only actually disappear once there is a 6.0, because > there doesn't seem to be any reason to expect PHP 6 to be "soon". Yeah, and I think(based on some mails and RFCs) that some people still don't understand/accepted that BC breaks are highly unlikely to be accepted to a minor release, but I think that people will wrap their heads around it.. > Unless a release within the next few years is numbered 6.0 (or something > else >5) simply to clean up the deprecated functionality, without actually > including major changes like the Unicode string concept. I think that the current tighter release cycle and stricter BC rules will mean that there will be more frequent major releases than it was usual in the past. I also think that maybe we should even introduce new branches/concepts like NEXT-MAJOR and NEXT-MINOR otherwise it will be a bit of a PITA to tell whether we should have a major release next, as the master branch contains a bunch of BC break changes, or that what changes should be reverted/not merged when we branch out a new minor version. But this topic should be discussed in a separate thread. -- Ferenc Kovács @Tyr43l - http://tyrael.hu