Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:69691
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.128.178 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAH-PCH77huE-+rSLHjCp8yx8UvCgrpEScT=obzTsLd4vhF5f1Q@mail.gmail.com>
References: <CAH-PCH77huE-+rSLHjCp8yx8UvCgrpEScT=obzTsLd4vhF5f1Q@mail.gmail.com>
Date: Fri, 18 Oct 2013 18:55:17 +0200
Message-ID: <CAF+90c_iNUX2+kse3efgH-4RzQWUyTkK94xiQ4rB1vMymNwfmg@mail.gmail.com>
To: Ferenc Kovacs <tyra3l@gmail.com>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=047d7b6dc6ee8f777204e906cc41
Subject: Re: [PHP-DEV] implication of the new release process regarding of new
 versions (moved from "Proposal to deprecate create_function()")
From: nikita.ppv@gmail.com (Nikita Popov)

--047d7b6dc6ee8f777204e906cc41
Content-Type: text/plain; charset=ISO-8859-1

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

--047d7b6dc6ee8f777204e906cc41--