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

On Fri, Oct 18, 2013 at 6:55 PM, Nikita Popov <nikita.ppv@gmail.com> wrote: > On Fri, Oct 18, 2013 at 6:29 PM, Ferenc Kovacs <tyra3l@gmail.com> wrote: > >> 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). >> > > I think the general interpretation of that passage is "Only minor BC > breaks possible". I.e. BC breaks only in uncommonly used functionality > (removal of logo functions) or changes with little "direct" impact (like > deprecation, which usually is super-annoying for people, but can be turned > off if you want). > > Nikita > The rfc shouldn't really leave place for the interpretation. I agree that the general consensus is that introducing new notices/warnings/etc. is not a BC break. The removal of the logo functions was a BC break, even thought that probably didn't affect too many people (I have seen at least one person on twitter mentioning using those functions), so that was against the rules of the relese process RFC. If we want to keep that kind of liberty, the RFC should be updated to reflect that. But I want to discuss another thing from my initial mail, the next-minor branch. Now that it seems to be "official" that we will be the RMs for 5.6, we were talking about creating the branch, which is still a PITA, because we can (and will) have backward incompatible changes in master, which means that we either have to branch the next minor version from master and (find then)revert the BC breaks from the newly created branch, or we could branch from 5.5 then cherrypick everything (500+ commits) except the offending ones. For now, I guess we will go with the branch from master, but for future versions, it would be really nice if we could introduce a new branch, PHP-5-NEXT, where you can commit anything which can be released with the next php 5.x version. (Yes, this means that instead of 5.3(sec only) -> 5.4 -> 5.5 -> 5.6 -> master you have to do PHP-5.3(sec only) -> PHP-5.4 -> PHP-5.5 -> PHP-5.6 -> PHP-5-NEXT -> master) But this would allow us to always keep track of that what kind of changes do we have BC wise, and can help us decide whether a minor or a major release is appropriate, plus creating a new version would be always straight forward: branch from PHP-5-NEXT for a minor, branch from master for a major version. -- Ferenc Kovács @Tyr43l - http://tyrael.hu