FAQ
Hi Internals

It's already mid-october and according to our release schedule we have to
release PHP 5.6 in 10 months from now. The past has shown that we need
approx 5 months to stablize a release and go through alpha, beta and RC
stages. Therefore I want to start a discussion on how to move forward
with 5.6, to get a release schedule up as fast as possible so contributors
now when to push their stuff and to vote on RFC's BEFORE the first beta.

I think over the last years it proved to be good to have the current
RM support a new RM who then takes over after the final release
(e.g. Julien basically does 5.5 alone now, but we worked a lot together
during alpha/beta/RC). Therefore my suggestion is that Julien is going to
help out with 5.6 and then we would need a new RM that can learn from julien
on how to do things to later be able to do 5.6 on his own.

Suggestions?

David

Search Discussions

  • Ferenc Kovacs at Oct 15, 2013 at 12:19 pm

    On Mon, Oct 14, 2013 at 11:43 PM, David Soria Parra wrote:

    Hi Internals

    It's already mid-october and according to our release schedule we have to
    release PHP 5.6 in 10 months from now. The past has shown that we need
    approx 5 months to stablize a release and go through alpha, beta and RC
    stages. Therefore I want to start a discussion on how to move forward
    with 5.6, to get a release schedule up as fast as possible so contributors
    now when to push their stuff and to vote on RFC's BEFORE the first beta.

    I think over the last years it proved to be good to have the current
    RM support a new RM who then takes over after the final release
    (e.g. Julien basically does 5.5 alone now, but we worked a lot together
    during alpha/beta/RC). Therefore my suggestion is that Julien is going to
    help out with 5.6 and then we would need a new RM that can learn from
    julien
    on how to do things to later be able to do 5.6 on his own.

    Suggestions?

    David

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
    I agree with all of the points above.

    I also think that we could be a bit more pro-active with the already
    presented RFCs and try to bug the authors or chip in with the
    implementation so that we don't end up in a situation where every new
    language construct comes in at the last minute (before or even after the
    feature freeze).

    I also think that not that many people familiar with what exactly an RM
    does, so I think (hope) that the lack of volunteers/candidates for RMing
    was caused by the fact that most people don't know what are the
    requirements for being an RM.

    From my understanding it is a little bit of project management and
    resolving some disputes whether or not some feature should be
    approved/rejected(usually you just point to
    https://wiki.php.net/rfc/releaseprocess RFC), but most of the times it is
    just following
    http://git.php.net/?p=php-src.git;a=blob_plain;f=README.RELEASE_PROCESS, so
    tagging/packaging the release, writing the release announcement, etc.

    Personally I would propose Nikic to the post, but I would also happy if
    Johannes or Stas would be a returning RM for the 5.6 release.


    --
    Ferenc Kovács
    @Tyr43l - http://tyrael.hu
  • David Soria Parra at Oct 15, 2013 at 2:46 pm

    On 10/15/2013 05:19 AM, Ferenc Kovacs wrote:
    From my understanding it is a little bit of project management and
    resolving some disputes whether or not some feature should be
    approved/rejected(usually you just point to
    https://wiki.php.net/rfc/releaseprocess RFC), but most of the times
    it is just following
    http://git.php.net/?p=php-src.git;a=blob_plain;f=README.RELEASE_PROCESS,
    so tagging/packaging the release, writing the release announcement, etc.

    It is mostly project managing and QA. During alpha/beta phase it is
    manging and creating lists of things that need to be done and asking
    the people to do it as well as keeping and eye on RFC discussions, etc.
    During beta/RC it is checking that nobody is adding new features, etc
    and judging if the current implemented features are mature enough to
    be kept (but don't mistaken this as a decision as to "what" goes it,
    that's RFCs + votes). In the end it's your responsibility to release a
    mature software that can be deployed by millions of people. Once
    released your main job as an RM is to keep an eye on security related
    bugs and follow the release process as much as possible. It's also a
    lot of talking to other RMs in order to release bugfixes, etc
    together, ensure we have a CVE, ensure that announcments are correct, etc.

    So it's just managing and checking that people do follow RFCs and that
    the project itself is following the release process rfc.

    David
  • Julien Pauli at Oct 15, 2013 at 1:11 pm

    On Mon, Oct 14, 2013 at 11:43 PM, David Soria Parra wrote:

    Hi Internals

    It's already mid-october and according to our release schedule we have to
    release PHP 5.6 in 10 months from now. The past has shown that we need
    approx 5 months to stablize a release and go through alpha, beta and RC
    stages. Therefore I want to start a discussion on how to move forward
    with 5.6, to get a release schedule up as fast as possible so contributors
    now when to push their stuff and to vote on RFC's BEFORE the first beta.

    I think over the last years it proved to be good to have the current
    RM support a new RM who then takes over after the final release
    (e.g. Julien basically does 5.5 alone now, but we worked a lot together
    during alpha/beta/RC). Therefore my suggestion is that Julien is going to
    help out with 5.6 and then we would need a new RM that can learn from
    julien
    on how to do things to later be able to do 5.6 on his own.
    I'm OK to work together with our future 5.6 RM :-)
    Let's start finding someone then

    Julien.Pauli
  • Pierre Joye at Oct 15, 2013 at 1:32 pm
    hi David,
    On Mon, Oct 14, 2013 at 11:43 PM, David Soria Parra wrote:
    Hi Internals

    It's already mid-october and according to our release schedule we have to
    release PHP 5.6 in 10 months from now. The past has shown that we need
    approx 5 months to stablize a release and go through alpha, beta and RC
    stages. Therefore I want to start a discussion on how to move forward
    with 5.6, to get a release schedule up as fast as possible so contributors
    now when to push their stuff and to vote on RFC's BEFORE the first beta.
    I will add some of the known TODOs to https://wiki.php.net/todo/php56
    in the next couple of days.
    I think over the last years it proved to be good to have the current
    RM support a new RM who then takes over after the final release
    (e.g. Julien basically does 5.5 alone now, but we worked a lot together
    during alpha/beta/RC). Therefore my suggestion is that Julien is going to
    help out with 5.6 and then we would need a new RM that can learn from julien
    on how to do things to later be able to do 5.6 on his own.

    Suggestions?
    I can do it if necessary, we (ostc team) are part of it anyway from a
    QA and windows point of view.


    Cheers,
    --
    Pierre

    @pierrejoye | http://www.libgd.org
  • Ondřej Surý at Oct 16, 2013 at 6:40 am
    Hi Inf^Hternals,

    Debian freeze will happen in 14 months, that means that we might be able
    to squeeze PHP 5.6 into next Debian stable.

    One question though – do you envision that the module ABI will change in
    PHP 5.6? (e.g. are there already plans to do so?) Obviously not
    changing ABI would make things much more simpler since it won't require
    the transition. Knowing before hand would also making things simpler
    since I could get pre-approval from Debian release team.

    Ondrej
    --
    Ondřej Surý <ondrej@sury.org>
    Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server
    On Mon, Oct 14, 2013, at 23:43, David Soria Parra wrote:
    Hi Internals

    It's already mid-october and according to our release schedule we have to
    release PHP 5.6 in 10 months from now. The past has shown that we need
    approx 5 months to stablize a release and go through alpha, beta and RC
    stages. Therefore I want to start a discussion on how to move forward
    with 5.6, to get a release schedule up as fast as possible so
    contributors
    now when to push their stuff and to vote on RFC's BEFORE the first beta.

    I think over the last years it proved to be good to have the current
    RM support a new RM who then takes over after the final release
    (e.g. Julien basically does 5.5 alone now, but we worked a lot together
    during alpha/beta/RC). Therefore my suggestion is that Julien is going to
    help out with 5.6 and then we would need a new RM that can learn from
    julien
    on how to do things to later be able to do 5.6 on his own.

    Suggestions?

    David

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
  • Pierre Joye at Oct 16, 2013 at 6:51 am
    hi Ondřej!
    On Wed, Oct 16, 2013 at 8:40 AM, Ondřej Surý wrote:
    Hi Inf^Hternals,

    Debian freeze will happen in 14 months, that means that we might be able
    to squeeze PHP 5.6 into next Debian stable.

    One question though – do you envision that the module ABI will change in
    PHP 5.6? (e.g. are there already plans to do so?) Obviously not
    changing ABI would make things much more simpler since it won't require
    the transition. Knowing before hand would also making things simpler
    since I could get pre-approval from Debian release team.
    We surely may change it yes. Mainly due to better 64bit support,
    size_t and int(32|64)_t usage. That will impact a lot of code, in core
    or in external extensions. Help welcome in this area as it is a huge
    effort.

    Some remaining missing TSRMLS_* usage may be added as well.

    Cheers,
    --
    Pierre

    @pierrejoye | http://www.libgd.org
  • Rasmus Lerdorf at Oct 16, 2013 at 9:03 am

    On 10/16/2013 09:40 AM, Ondřej Surý wrote:
    Hi Inf^Hternals,

    Debian freeze will happen in 14 months, that means that we might be able
    to squeeze PHP 5.6 into next Debian stable.

    One question though – do you envision that the module ABI will change in
    PHP 5.6? (e.g. are there already plans to do so?) Obviously not
    changing ABI would make things much more simpler since it won't require
    the transition. Knowing before hand would also making things simpler
    since I could get pre-approval from Debian release team.
    Yes, chances are good that it won't be ABI compatible. I don't think we
    have ever had a X.Y relased that was completely ABI compatible with X.Y-1.

    -Rasmus
  • David Soria Parra at Oct 17, 2013 at 5:24 am

    David Soria Parra schrieb:
    I think over the last years it proved to be good to have the current
    RM support a new RM who then takes over after the final release
    (e.g. Julien basically does 5.5 alone now, but we worked a lot together
    during alpha/beta/RC). Therefore my suggestion is that Julien is going to
    help out with 5.6 and then we would need a new RM that can learn from julien
    on how to do things to later be able to do 5.6 on his own.
    So I mabe think Ferenic (tyrael) would be a good RM. He has been involved
    with the project for the last 3 years and knows the community, the code
    and infrastrucutre well. He followed the RFC process and knows most of the
    core devs in order to be able to manage them good. Indeed he hasn't hacked
    on the Zend Engine itself, but I think together with Julien he probably
    do a fine job. suggestions?

    David
  • Julien Pauli at Oct 17, 2013 at 2:25 pm

    On Thu, Oct 17, 2013 at 7:24 AM, David Soria Parra wrote:

    David Soria Parra <dsp@php.net> schrieb:
    I think over the last years it proved to be good to have the current
    RM support a new RM who then takes over after the final release
    (e.g. Julien basically does 5.5 alone now, but we worked a lot together
    during alpha/beta/RC). Therefore my suggestion is that Julien is going to
    help out with 5.6 and then we would need a new RM that can learn from julien
    on how to do things to later be able to do 5.6 on his own.
    So I mabe think Ferenic (tyrael) would be a good RM. He has been involved
    with the project for the last 3 years and knows the community, the code
    and infrastrucutre well. He followed the RFC process and knows most of the
    core devs in order to be able to manage them good. Indeed he hasn't hacked
    on the Zend Engine itself, but I think together with Julien he probably
    do a fine job. suggestions?

    Yep, Ferenic and myself usually agree together, and we already have
    performed complementary tasks :-)
    I'm all +1 for Ferenic (tyrael)

    Julien
  • Felipe Pena at Oct 17, 2013 at 2:30 pm

    On Thu, Oct 17, 2013 at 11:24 AM, Julien Pauli wrote:
    On Thu, Oct 17, 2013 at 7:24 AM, David Soria Parra wrote:

    David Soria Parra <dsp@php.net> schrieb:
    I think over the last years it proved to be good to have the current
    RM support a new RM who then takes over after the final release
    (e.g. Julien basically does 5.5 alone now, but we worked a lot together
    during alpha/beta/RC). Therefore my suggestion is that Julien is going to
    help out with 5.6 and then we would need a new RM that can learn from julien
    on how to do things to later be able to do 5.6 on his own.
    So I mabe think Ferenic (tyrael) would be a good RM. He has been involved
    with the project for the last 3 years and knows the community, the code
    and infrastrucutre well. He followed the RFC process and knows most of the
    core devs in order to be able to manage them good. Indeed he hasn't hacked
    on the Zend Engine itself, but I think together with Julien he probably
    do a fine job. suggestions?

    Yep, Ferenic and myself usually agree together, and we already have
    performed complementary tasks :-)
    I'm all +1 for Ferenic (tyrael)

    Julien
    +1 for Ferenc Kovacs. (is it a voting thread? :D)

    --
    Regards,
    Felipe Pena
  • Michael Wallner at Oct 17, 2013 at 2:56 pm

    On 17 October 2013 16:29, Felipe Pena wrote:
    +1 for Ferenc Kovacs. (is it a voting thread? :D)
    +1 (let's make it a good ol' one :))


    --
    Regards,
    Mike
  • Pierre Joye at Oct 17, 2013 at 3:29 pm

    On Thu, Oct 17, 2013 at 7:56 AM, Michael Wallner wrote:
    On 17 October 2013 16:29, Felipe Pena wrote:


    +1 for Ferenc Kovacs. (is it a voting thread? :D)
    +1 (let's make it a good ol' one :))
    +1 for both


    --
    Pierre

    @pierrejoye | http://www.libgd.org
  • Ferenc Kovacs at Oct 18, 2013 at 5:19 am

    On Thu, Oct 17, 2013 at 5:29 PM, Pierre Joye wrote:
    On Thu, Oct 17, 2013 at 7:56 AM, Michael Wallner wrote:
    On 17 October 2013 16:29, Felipe Pena wrote:


    +1 for Ferenc Kovacs. (is it a voting thread? :D)
    +1 (let's make it a good ol' one :))
    +1 for both


    --
    Pierre

    @pierrejoye | http://www.libgd.org

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
    Hi,

    thank you guys for the support, it means a lot!

    --
    Ferenc Kovács
    @Tyr43l - http://tyrael.hu
  • Christopher Jones at Oct 23, 2013 at 5:47 pm

    On 10/17/2013 10:19 PM, Ferenc Kovacs wrote:
    On Thu, Oct 17, 2013 at 5:29 PM, Pierre Joye wrote:
    On Thu, Oct 17, 2013 at 7:56 AM, Michael Wallner wrote:
    On 17 October 2013 16:29, Felipe Pena wrote:


    +1 for Ferenc Kovacs. (is it a voting thread? :D)
    +1 (let's make it a good ol' one :))
    +1 for both


    --
    Pierre

    @pierrejoye | http://www.libgd.org

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
    Hi,

    thank you guys for the support, it means a lot!
    +1.

    Chris
  • Derick Rethans at Nov 6, 2013 at 1:44 pm

    On Thu, 17 Oct 2013, Michael Wallner wrote:
    On 17 October 2013 16:29, Felipe Pena wrote:


    +1 for Ferenc Kovacs. (is it a voting thread? :D)
    +1 (let's make it a good ol' one :))
    Not that I'm objecting, but I think it would probably a good idea (for
    next time) to have an RFC style vote (with "VOTE" in the subject) with
    perhaps different options for this?

    cheers,
    Derick
  • Ferenc Kovacs at Nov 6, 2013 at 1:47 pm

    On Wed, Nov 6, 2013 at 2:44 PM, Derick Rethans wrote:
    On Thu, 17 Oct 2013, Michael Wallner wrote:
    On 17 October 2013 16:29, Felipe Pena wrote:


    +1 for Ferenc Kovacs. (is it a voting thread? :D)
    +1 (let's make it a good ol' one :))
    Not that I'm objecting, but I think it would probably a good idea (for
    next time) to have an RFC style vote (with "VOTE" in the subject) with
    perhaps different options for this?

    cheers,
    Derick

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
    +1 for having some kind of official process for this.

    --
    Ferenc Kovács
    @Tyr43l - http://tyrael.hu
  • Sherif Ramadan at Oct 23, 2013 at 6:57 pm

    On Thu, Oct 17, 2013 at 1:24 AM, David Soria Parra wrote:

    David Soria Parra <dsp@php.net> schrieb:
    I think over the last years it proved to be good to have the current
    RM support a new RM who then takes over after the final release
    (e.g. Julien basically does 5.5 alone now, but we worked a lot together
    during alpha/beta/RC). Therefore my suggestion is that Julien is going to
    help out with 5.6 and then we would need a new RM that can learn from julien
    on how to do things to later be able to do 5.6 on his own.
    So I mabe think Ferenic (tyrael) would be a good RM.

    I'm all for that as well :)

    +1
  • Julien Pauli at Oct 29, 2013 at 8:23 am

    On Wed, Oct 23, 2013 at 8:57 PM, Sherif Ramadan wrote:
    On Thu, Oct 17, 2013 at 1:24 AM, David Soria Parra wrote:

    David Soria Parra <dsp@php.net> schrieb:
    I think over the last years it proved to be good to have the current
    RM support a new RM who then takes over after the final release
    (e.g. Julien basically does 5.5 alone now, but we worked a lot together
    during alpha/beta/RC). Therefore my suggestion is that Julien is going
    to
    help out with 5.6 and then we would need a new RM that can learn from julien
    on how to do things to later be able to do 5.6 on his own.
    So I mabe think Ferenic (tyrael) would be a good RM.

    I'm all for that as well :)

    +1
    Hi back !

    I suggest we move forward on the topic.

    We're gonna enter November soon, this is a dead line to branch 5.6.

    I suggest we branch 5.6 from master, then run the 5.5 test suite against
    the branch, and remove every commit that leads to a BC break.
    The task shouldn't be too hard.

    When the branch is created, the wiki then would have to be updated to show
    the ideas we'd like to support (https://wiki.php.net/todo/php56)

    Julien Pauli
  • Ferenc Kovacs at Oct 29, 2013 at 8:40 am

    On Tue, Oct 29, 2013 at 9:22 AM, Julien Pauli wrote:

    On Wed, Oct 23, 2013 at 8:57 PM, Sherif Ramadan <theanomaly.is@gmail.com
    wrote:
    On Thu, Oct 17, 2013 at 1:24 AM, David Soria Parra wrote:

    David Soria Parra <dsp@php.net> schrieb:
    I think over the last years it proved to be good to have the current
    RM support a new RM who then takes over after the final release
    (e.g. Julien basically does 5.5 alone now, but we worked a lot
    together
    during alpha/beta/RC). Therefore my suggestion is that Julien is
    going
    to
    help out with 5.6 and then we would need a new RM that can learn from julien
    on how to do things to later be able to do 5.6 on his own.
    So I mabe think Ferenic (tyrael) would be a good RM.

    I'm all for that as well :)

    +1
    Hi back !

    I suggest we move forward on the topic.

    We're gonna enter November soon, this is a dead line to branch 5.6.

    I suggest we branch 5.6 from master, then run the 5.5 test suite against
    the branch, and remove every commit that leads to a BC break.
    The task shouldn't be too hard.

    When the branch is created, the wiki then would have to be updated to show
    the ideas we'd like to support (https://wiki.php.net/todo/php56)

    Julien Pauli

    Hi,

    I was working on that last week, there are a couple of test related changes
    which should/could be backported to 5.5 (and maybe even 5.4):
    http://git.php.net/?p=php-src.git;a=commitdiff;h=ecbe4af0de94c629fa5ba8ab169654e00c958bad
    http://git.php.net/?p=php-src.git;a=commitdiff;h=361e984e462de5422bba5470d3961e67de327396
    http://git.php.net/?p=php-src.git;a=commitdiff;h=95017c0522a9a1b9527d7cc1d866fbc3b89df7ac
    I have sent an email to Sara/ptarjan, but got no response yet:
    http://permalink.gmane.org/gmane.comp.php.cvs.general/62834

    The sole BC break I've found yet was the removal of $HTTP_RAW_POST_DATA and
    co from Mike:
    http://git.php.net/?p=php-src.git;a=commitdiff;h=423c70fb4d79b7831b1db41ea217c8e1afd5cf8e
    http://git.php.net/?p=php-src.git;a=commitdiff;h=449d4c0b1c6ea0f5dfe7b56c99d9fc4f2033d27c
    http://git.php.net/?p=php-src.git;a=commitdiff;h=4a3936ef4abdeb72c7d323fe4b6a65e1ae0ef181
    http://git.php.net/?p=php-src.git;a=commitdiff;h=8d087dc0d7c88e26539646875dc0f7bb5042187b

    This would be a measurable improvement for many of our users with a
    relatively easy way to restore/emulate the old behavior
    ($HTTP_RAW_POST_DATA = file_get_contents("php://input");) so maybe it
    should be worth a discussion whether or not we should revert it from 5.6.

    --
    Ferenc Kovács
    @Tyr43l - http://tyrael.hu
  • Julien Pauli at Nov 5, 2013 at 6:04 pm

    On Tue, Oct 29, 2013 at 9:40 AM, Ferenc Kovacs wrote:

    On Tue, Oct 29, 2013 at 9:22 AM, Julien Pauli wrote:

    On Wed, Oct 23, 2013 at 8:57 PM, Sherif Ramadan <theanomaly.is@gmail.com
    wrote:
    On Thu, Oct 17, 2013 at 1:24 AM, David Soria Parra wrote:

    David Soria Parra <dsp@php.net> schrieb:
    I think over the last years it proved to be good to have the current
    RM support a new RM who then takes over after the final release
    (e.g. Julien basically does 5.5 alone now, but we worked a lot
    together
    during alpha/beta/RC). Therefore my suggestion is that Julien is
    going
    to
    help out with 5.6 and then we would need a new RM that can learn
    from
    julien
    on how to do things to later be able to do 5.6 on his own.
    So I mabe think Ferenic (tyrael) would be a good RM.

    I'm all for that as well :)

    +1
    Hi back !

    I suggest we move forward on the topic.

    We're gonna enter November soon, this is a dead line to branch 5.6.

    I suggest we branch 5.6 from master, then run the 5.5 test suite against
    the branch, and remove every commit that leads to a BC break.
    The task shouldn't be too hard.

    When the branch is created, the wiki then would have to be updated to show
    the ideas we'd like to support (https://wiki.php.net/todo/php56)

    Julien Pauli

    Hi,

    I was working on that last week, there are a couple of test related
    changes which should/could be backported to 5.5 (and maybe even 5.4):

    http://git.php.net/?p=php-src.git;a=commitdiff;h=ecbe4af0de94c629fa5ba8ab169654e00c958bad

    http://git.php.net/?p=php-src.git;a=commitdiff;h=361e984e462de5422bba5470d3961e67de327396

    http://git.php.net/?p=php-src.git;a=commitdiff;h=95017c0522a9a1b9527d7cc1d866fbc3b89df7ac
    I have sent an email to Sara/ptarjan, but got no response yet:
    http://permalink.gmane.org/gmane.comp.php.cvs.general/62834

    The sole BC break I've found yet was the removal of $HTTP_RAW_POST_DATA
    and co from Mike:

    http://git.php.net/?p=php-src.git;a=commitdiff;h=423c70fb4d79b7831b1db41ea217c8e1afd5cf8e

    http://git.php.net/?p=php-src.git;a=commitdiff;h=449d4c0b1c6ea0f5dfe7b56c99d9fc4f2033d27c

    http://git.php.net/?p=php-src.git;a=commitdiff;h=4a3936ef4abdeb72c7d323fe4b6a65e1ae0ef181

    http://git.php.net/?p=php-src.git;a=commitdiff;h=8d087dc0d7c88e26539646875dc0f7bb5042187b

    This would be a measurable improvement for many of our users with a
    relatively easy way to restore/emulate the old behavior
    ($HTTP_RAW_POST_DATA = file_get_contents("php://input");) so maybe it
    should be worth a discussion whether or not we should revert it from 5.6.
    Mmmm, that's a break anyway, even if we provide solutions against it.
    Can we afford it ?


    Anyway, we should branch this week please.
    I can give time this week to help on stuff, unfortunately I wont have time
    this week-end but next one :-p


    Julien.Pauli
  • Ferenc Kovacs at Nov 6, 2013 at 9:19 am

    On Tue, Nov 5, 2013 at 7:03 PM, Julien Pauli wrote:
    On Tue, Oct 29, 2013 at 9:40 AM, Ferenc Kovacs wrote:



    On Tue, Oct 29, 2013 at 9:22 AM, Julien Pauli wrote:

    On Wed, Oct 23, 2013 at 8:57 PM, Sherif Ramadan <theanomaly.is@gmail.com
    wrote:
    On Thu, Oct 17, 2013 at 1:24 AM, David Soria Parra <dsp@php.net>
    wrote:
    David Soria Parra <dsp@php.net> schrieb:
    I think over the last years it proved to be good to have the
    current
    RM support a new RM who then takes over after the final release
    (e.g. Julien basically does 5.5 alone now, but we worked a lot
    together
    during alpha/beta/RC). Therefore my suggestion is that Julien is
    going
    to
    help out with 5.6 and then we would need a new RM that can learn
    from
    julien
    on how to do things to later be able to do 5.6 on his own.
    So I mabe think Ferenic (tyrael) would be a good RM.

    I'm all for that as well :)

    +1
    Hi back !

    I suggest we move forward on the topic.

    We're gonna enter November soon, this is a dead line to branch 5.6.

    I suggest we branch 5.6 from master, then run the 5.5 test suite against
    the branch, and remove every commit that leads to a BC break.
    The task shouldn't be too hard.

    When the branch is created, the wiki then would have to be updated to
    show
    the ideas we'd like to support (https://wiki.php.net/todo/php56)

    Julien Pauli

    Hi,

    I was working on that last week, there are a couple of test related
    changes which should/could be backported to 5.5 (and maybe even 5.4):

    http://git.php.net/?p=php-src.git;a=commitdiff;h=ecbe4af0de94c629fa5ba8ab169654e00c958bad

    http://git.php.net/?p=php-src.git;a=commitdiff;h=361e984e462de5422bba5470d3961e67de327396

    http://git.php.net/?p=php-src.git;a=commitdiff;h=95017c0522a9a1b9527d7cc1d866fbc3b89df7ac
    I have sent an email to Sara/ptarjan, but got no response yet:
    http://permalink.gmane.org/gmane.comp.php.cvs.general/62834

    The sole BC break I've found yet was the removal of $HTTP_RAW_POST_DATA
    and co from Mike:

    http://git.php.net/?p=php-src.git;a=commitdiff;h=423c70fb4d79b7831b1db41ea217c8e1afd5cf8e

    http://git.php.net/?p=php-src.git;a=commitdiff;h=449d4c0b1c6ea0f5dfe7b56c99d9fc4f2033d27c

    http://git.php.net/?p=php-src.git;a=commitdiff;h=4a3936ef4abdeb72c7d323fe4b6a65e1ae0ef181

    http://git.php.net/?p=php-src.git;a=commitdiff;h=8d087dc0d7c88e26539646875dc0f7bb5042187b

    This would be a measurable improvement for many of our users with a
    relatively easy way to restore/emulate the old behavior
    ($HTTP_RAW_POST_DATA = file_get_contents("php://input");) so maybe it
    should be worth a discussion whether or not we should revert it from 5.6.
    Mmmm, that's a break anyway, even if we provide solutions against it.
    Can we afford it ?
    I'm not fond of the idea myself, but I can see why others would disagree.
    I will revert it from 5.6 though, and we can discuss it later.


    Anyway, we should branch this week please.
    I can give time this week to help on stuff, unfortunately I wont have time
    this week-end but next one :-p
    I will branch it today from master (without the raw post data BC break).

    --
    Ferenc Kovács
    @Tyr43l - http://tyrael.hu
  • Matt F at Nov 6, 2013 at 10:28 pm
    I have been running master and 5_5 PHPT tests against master snapshot
    builds on all versions of Windows.

    I have run the 5.5.6RC1 test-pack against snapshot builds of
    master-ra0244a6 (x86, x64, ts and nts) and found no functional regressions
    (no additional failures, timeouts or crashes) from php 5.5.6rc1, including
    the x64 builds.
    On Tue, Oct 29, 2013 at 1:22 AM, Julien Pauli wrote:

    On Wed, Oct 23, 2013 at 8:57 PM, Sherif Ramadan <theanomaly.is@gmail.com
    wrote:
    On Thu, Oct 17, 2013 at 1:24 AM, David Soria Parra wrote:

    David Soria Parra <dsp@php.net> schrieb:
    I think over the last years it proved to be good to have the current
    RM support a new RM who then takes over after the final release
    (e.g. Julien basically does 5.5 alone now, but we worked a lot
    together
    during alpha/beta/RC). Therefore my suggestion is that Julien is
    going
    to
    help out with 5.6 and then we would need a new RM that can learn from julien
    on how to do things to later be able to do 5.6 on his own.
    So I mabe think Ferenic (tyrael) would be a good RM.

    I'm all for that as well :)

    +1
    Hi back !

    I suggest we move forward on the topic.

    We're gonna enter November soon, this is a dead line to branch 5.6.

    I suggest we branch 5.6 from master, then run the 5.5 test suite against
    the branch, and remove every commit that leads to a BC break.
    The task shouldn't be too hard.
    I get the same pass rate (no additional failures) for master ra0244a6 as I
    get for 5.5.6rc1. We build the same extensions for 5.5 and master on
    Windows, so the test coverage is the same. Forking master to 5.6 doesn't
    seem to be a problem on Windows at least(no BC issues, etc...).

    For more info, see
    http://windows.php.net/downloads/snaps/ostc/pftt/PHP_Master/

    -Matt

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupphp-internals @
categoriesphp
postedOct 14, '13 at 9:43p
activeNov 6, '13 at 10:28p
posts23
users13
websitephp.net

People

Translate

site design / logo © 2022 Grokbase