FAQ

On Fri, Oct 18, 2013 at 6:03 PM, Rowan Collins 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

Search Discussions

  • Nikita Popov at Oct 18, 2013 at 4:55 pm

    On Fri, Oct 18, 2013 at 6:29 PM, Ferenc Kovacs wrote:
    On Fri, Oct 18, 2013 at 6:03 PM, Rowan Collins 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
    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
  • Ferenc Kovacs at Oct 21, 2013 at 12:39 pm

    On Fri, Oct 18, 2013 at 6:55 PM, Nikita Popov wrote:
    On Fri, Oct 18, 2013 at 6:29 PM, Ferenc Kovacs 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
    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
    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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupphp-internals @
categoriesphp
postedOct 18, '13 at 4:30p
activeOct 21, '13 at 12:39p
posts3
users2
websitephp.net

2 users in discussion

Ferenc Kovacs: 2 posts Nikita Popov: 1 post

People

Translate

site design / logo © 2022 Grokbase