Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:69690
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.223.178 as permitted sender)
MIME-Version: 1.0
Date: Fri, 18 Oct 2013 18:29:57 +0200
Message-ID: <CAH-PCH77huE-+rSLHjCp8yx8UvCgrpEScT=obzTsLd4vhF5f1Q@mail.gmail.com>
To: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=047d7bdc1172f0cc2f04e9067157
Subject: implication of the new release process regarding of new versions
 (moved from "Proposal to deprecate create_function()")
From: tyra3l@gmail.com (Ferenc Kovacs)

--047d7bdc1172f0cc2f04e9067157
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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 featur=
es
>> for 5.4.0 which were already removed in the 6.0 branch), but if you chec=
k
>> out http://hu1.php.net/manual/en/**migration55.incompatible.php<http://h=
u1.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 mean=
t
>> 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 i=
t
> 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 guarantee=
d
> 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 actuall=
y
> 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.


--=20
Ferenc Kov=C3=A1cs
@Tyr43l - http://tyrael.hu

--047d7bdc1172f0cc2f04e9067157--