Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:69731
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.223.177 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAF+90c_iNUX2+kse3efgH-4RzQWUyTkK94xiQ4rB1vMymNwfmg@mail.gmail.com>
References: <CAH-PCH77huE-+rSLHjCp8yx8UvCgrpEScT=obzTsLd4vhF5f1Q@mail.gmail.com>
	<CAF+90c_iNUX2+kse3efgH-4RzQWUyTkK94xiQ4rB1vMymNwfmg@mail.gmail.com>
Date: Mon, 21 Oct 2013 14:39:29 +0200
Message-ID: <CAH-PCH6-sj_a1S1X9Oh78=cZMusQx+5SHR0wFam-c4PTfL05xw@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=90e6ba6138c23f643104e93f93cd
Subject: Re: [PHP-DEV] implication of the new release process regarding of new
 versions (moved from "Proposal to deprecate create_function()")
From: tyra3l@gmail.com (Ferenc Kovacs)

--90e6ba6138c23f643104e93f93cd
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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 happ=
en
>> >> (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 mad=
e
>> 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 turne=
d
> 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.

--=20
Ferenc Kov=C3=A1cs
@Tyr43l - http://tyrael.hu

--90e6ba6138c23f643104e93f93cd--