FAQ
Given the current state of trunk, I think 5.4 release process should
not begin tomorrow (alpha or whatever other status). There are
numerous identified issues that we need to fix before even think to
begin with a release. For example:

- type hinting (or strict hinting)
- no consensus
- the RFCs are unclear
- BC break introduced
. classes named as any of the type hint scalar types
do not work anymore
aka class int {}

- Traits may not be ready yet for pre-release
- see http://svn.php.net/viewvc?view=revision&revision=298348
- APC support

- There are many changes not BC with 5.x, as we allowed them for the
development tree, before 5.4 was even a topic

- APC is not yet bundled. Having the opcode bundle can raise issues by
one or another, we should have it in from the very 1st release

- pecl/http was planned to be bundled. What's the status?

We also have no plan about what will or will not be 5.4. This looks
familiar, this is exactly how we begun 5.3 and it tooks literally
years to be released. There is also actually no agreement to begin
with 5.4 now.

5.4 should be hold off until we solved the listed issues and the
release management RFC gets discussed and hopefully approved.

Thanks.

--
Regards,
Felipe Pena

Search Discussions

  • Stas Malyshev at Nov 23, 2010 at 1:35 am
    Hi!
    Given the current state of trunk, I think 5.4 release process should
    not begin tomorrow (alpha or whatever other status). There are
    numerous identified issues that we need to fix before even think to
    begin with a release. For example:
    I agree that it's better to discuss RC process RFC before starting the
    actual RC process.
    - There are many changes not BC with 5.x, as we allowed them for the
    development tree, before 5.4 was even a topic
    Do you have a list of such changes?
    - APC is not yet bundled. Having the opcode bundle can raise issues by
    one or another, we should have it in from the very 1st release
    This can be done post-alpha, I think - it's not very important for the
    rest of the alpha, if there's a problem we can postpone it but I don't
    believe we should hold releases just for that (I do believe we should
    for other things though :)
    --
    Stanislav Malyshev, Software Architect
    SugarCRM: http://www.sugarcrm.com/
    (408)454-6900 ext. 227
  • Patrick ALLAERT at Nov 23, 2010 at 9:36 am

    2010/11/23 Felipe Pena <felipensp@gmail.com>:
    Given the current state of trunk, I think 5.4 release process should
    not begin tomorrow (alpha or whatever other status). There are
    numerous identified issues that we need to fix before even think to
    begin with a release. For example:

    - type hinting (or strict hinting)
    - no consensus
    - the RFCs are unclear
    - BC break introduced
    . classes named as any of the type hint scalar types
    do not work anymore
    aka class int {}

    - Traits may not be ready yet for pre-release
    - see http://svn.php.net/viewvc?view=revision&revision=298348
    - APC support

    - There are many changes not BC with 5.x, as we allowed them for the
    development tree, before 5.4 was even a topic

    - APC is not yet bundled. Having the opcode bundle can raise issues by
    one or another, we should have it in from the very 1st release

    - pecl/http was planned to be bundled. What's the status?

    We also have no plan about what will or will not be 5.4. This looks
    familiar, this is exactly how we begun 5.3 and it tooks literally
    years to be released. There is also actually no agreement to begin
    with 5.4 now.

    5.4 should be hold off until we solved the listed issues and the
    release management RFC gets discussed and hopefully approved.

    Thanks.

    --
    Regards,
    Felipe Pena
    Nor do we have a clear roadmap concerning the removal of magic quotes!
    Most would like to get rid of them, but some have concerns about doing
    it in 5.4.
    (Please, use the "Magic quotes in trunk" thread to comment on this
    one: http://news.php.net/php.internals/50301)

    --
    Patrick Allaert
    ---
    http://code.google.com/p/peclapm/ - Alternative PHP Monitor
  • Ferenc Kovacs at Nov 23, 2010 at 9:55 am

    On Tue, Nov 23, 2010 at 10:35 AM, Patrick ALLAERT wrote:

    2010/11/23 Felipe Pena <felipensp@gmail.com>:
    Given the current state of trunk, I think 5.4 release process should
    not begin tomorrow (alpha or whatever other status). There are
    numerous identified issues that we need to fix before even think to
    begin with a release. For example:

    - type hinting (or strict hinting)
    - no consensus
    - the RFCs are unclear
    - BC break introduced
    . classes named as any of the type hint scalar types
    do not work anymore
    aka class int {}

    - Traits may not be ready yet for pre-release
    - see http://svn.php.net/viewvc?view=revision&revision=298348
    - APC support

    - There are many changes not BC with 5.x, as we allowed them for the
    development tree, before 5.4 was even a topic

    - APC is not yet bundled. Having the opcode bundle can raise issues by
    one or another, we should have it in from the very 1st release

    - pecl/http was planned to be bundled. What's the status?

    We also have no plan about what will or will not be 5.4. This looks
    familiar, this is exactly how we begun 5.3 and it tooks literally
    years to be released. There is also actually no agreement to begin
    with 5.4 now.

    5.4 should be hold off until we solved the listed issues and the
    release management RFC gets discussed and hopefully approved.

    Thanks.

    --
    Regards,
    Felipe Pena
    Nor do we have a clear roadmap concerning the removal of magic quotes!
    Most would like to get rid of them, but some have concerns about doing
    it in 5.4.
    (Please, use the "Magic quotes in trunk" thread to comment on this
    one: http://news.php.net/php.internals/50301)
    And not just the magic quotes:
    http://www.pubbs.net/201011/php/28851-re-php-dev-magic-quotes-in-trunk.html
    with the current trunk, we dropped many deprecated legacy feature, which is
    nice, but breaks bc with a minor version.

    So I would favor a more sophisticated development and release
    policy/standard.
    and the current release is a "good" example why this is needed:
    first Rasmus and others said, that we shouldn't plan beforehand the next
    release, just start coding, and when we have enough staff, we can discuss
    and vote on the version number, release managers, what will be included in
    the release.
    then after some time, "magically" the RM's were selected (I didn't see the
    voting, maybe it happened via irc), and the 5.4 was selected for the next
    version without vote (maybe irc...), and there were selected a few change
    from the trunk for discussion, the most of them was included to the release
    without formal approval.
    :/

    Tyrael
  • Johannes Schlüter at Nov 23, 2010 at 11:06 am

    On Tue, 2010-11-23 at 10:55 +0100, Ferenc Kovacs wrote:
    and the 5.4 was selected for the next version without vote (maybe irc...)
    As we are not marketing-driven version numbers follow technical
    reasoning. There's no larger BC break (like a radical change in the
    object model like from 4 to 5) and no radical change to the string type
    (like from PHP 5 to PHP-Unicode) there's nothing to discuss about. :-)

    johannes
  • Stefan Marr at Nov 23, 2010 at 9:51 am
    Hi:
    On 23 Nov 2010, at 02:30, Felipe Pena wrote:

    - Traits may not be ready yet for pre-release
    - see http://svn.php.net/viewvc?view=revision&revision=298348
    The listed todos where:
    - Reflection API
    That was implemented by Johannes as far as I remember.

    - support for traits for internal classes
    - currently destroy_zend_class does not handle that case
    For support of internal classes was no clear interest yet, so it never got done.
    Is that a show stopper?

    Thanks
    Stefan



    --
    Stefan Marr
    Software Languages Lab
    Vrije Universiteit Brussel
    Pleinlaan 2 / B-1050 Brussels / Belgium
    http://soft.vub.ac.be/~smarr
    Phone: +32 2 629 2974
    Fax: +32 2 629 3525
  • Johannes Schlüter at Nov 23, 2010 at 11:05 am

    On Tue, 2010-11-23 at 10:51 +0100, Stefan Marr wrote:
    On 23 Nov 2010, at 02:30, Felipe Pena wrote:

    - Traits may not be ready yet for pre-release
    - see http://svn.php.net/viewvc?view=revision&revision=298348
    The listed todos where:
    - Reflection API
    That was implemented by Johannes as far as I remember.
    That is not 100% complete. I had an issue with Aliases and finding the
    original declaration or such. Will be done before we reach beta.
    - support for traits for internal classes
    - currently destroy_zend_class does not handle that case
    For support of internal classes was no clear interest yet, so it never
    got done.
    Is that a show stopper?
    Can Traits be declared internally and the issue is only about using
    them? I think we can live without using traits for internal classes
    easily (as we can already do that by aliasing the methods
    internally ;-) )

    Being able to provide traits might be interesting, but I don't see it as
    high priority task.

    johannes
  • Sebastian Bergmann at Nov 23, 2010 at 9:55 am

    Am 23.11.2010 02:30, schrieb Felipe Pena:
    classes named as any of the type hint scalar types do not work anymore
    Was it not a promise of the re2c/lemon migration to allow reserved words
    as class/function names?

    --
    Sebastian Bergmann Co-Founder and Principal Consultant
    http://sebastian-bergmann.de/ http://thePHP.cc/
  • Derick Rethans at Nov 23, 2010 at 9:57 am

    On Mon, 22 Nov 2010, Felipe Pena wrote:

    Given the current state of trunk, I think 5.4 release process should
    not begin tomorrow (alpha or whatever other status). There are
    numerous identified issues that we need to fix before even think to
    begin with a release. For example:

    - type hinting (or strict hinting)
    - no consensus
    - the RFCs are unclear
    - BC break introduced
    . classes named as any of the type hint scalar types
    do not work anymore
    aka class int {}
    Yeah, there is a slight hint of a BC break in case you have a class
    named "int" or "float" etc. But there is:
    http://uk.php.net/manual/en/userlandnaming.tips.php

    Perhaps we can reduce the current list of classes:
    int, integer, real, double, string, binary, scalar, array, object,
    bool, boolean
    to what the manual uses though (for prototypes):
    int, float, string, binary, scalar, array, object, bool
    (Point #18 at http://doc.php.net/php/dochowto/chapter-conventions.php)
    - Traits may not be ready yet for pre-release
    - see http://svn.php.net/viewvc?view=revision&revision=298348
    - APC support
    I don't see why this can't be done after post-branching/post-alpha1
    - There are many changes not BC with 5.x, as we allowed them for the
    development tree, before 5.4 was even a topic
    What's the list?
    - APC is not yet bundled. Having the opcode bundle can raise issues by
    one or another, we should have it in from the very 1st release
    Bundling it is a question of copying it over. It compiles, although I am
    not 100% whether it works. If it doesn't fit in the end in the timeline,
    we can always remove it again as it's a standalone extension.
    - pecl/http was planned to be bundled. What's the status?
    I'm all for it; but again, it's just copying it over to trunk before we
    branch.
    We also have no plan about what will or will not be 5.4. This looks
    familiar, this is exactly how we begun 5.3 and it tooks literally
    years to be released. There is also actually no agreement to begin
    with 5.4 now.
    Yes, but instead of defining "what is PHP 5.4", why not just go with
    what we have? Everything that's not in thre is for PHP-next-next again.
    5.4 should be hold off until we solved the listed issues and the
    release management RFC gets discussed and hopefully approved.
    Why do you need a release management RFC? We've made releases for more
    than a decade just fine.

    Stalling every time doesn't get us anywhere. IMO we should just go with
    it. Which means as a rough guide:

    - copy over APC/pecl_http
    - branch on thursday
    - alpha next week
    - build a list of things that needs doing in 5.4 to get it ready (with
    possible options to get rid of apc/pecl_http if they are not up to
    date enough)

    I am absolutely against stalling again!

    cheers,
    Derick

    --
    http://derickrethans.nl | http://xdebug.org
    Like Xdebug? Consider a donation: http://xdebug.org/donate.php
    twitter: @derickr and @xdebug
  • Sebastian Bergmann at Nov 23, 2010 at 10:02 am

    Am 23.11.2010 10:57, schrieb Derick Rethans:
    I am absolutely against stalling again!
    +1

    If there is anything that needs particular TLC (testing/loving/care),
    let me know. FYI, at the moment I am playing a lot with traits to get
    a(n updated) feel for them.

    --
    Sebastian Bergmann Co-Founder and Principal Consultant
    http://sebastian-bergmann.de/ http://thePHP.cc/
  • Ferenc Kovacs at Nov 23, 2010 at 11:16 am

    We also have no plan about what will or will not be 5.4. This looks
    familiar, this is exactly how we begun 5.3 and it tooks literally
    years to be released. There is also actually no agreement to begin
    with 5.4 now.
    Yes, but instead of defining "what is PHP 5.4", why not just go with
    what we have? Everything that's not in thre is for PHP-next-next again.
    backward compatibility™
    we had a few nice things in the PHP6 branch, which got merged into the
    trunk, before choosing the version number for the trunk.
    it's okay, but we agreed on that if that gets into the trunk, that it
    doesn't mean, that it will be shipped automatically with the next release.
    you can read again the fuss about the scalar type hinting:
    after a release, we start to think trunk as a development branch, where
    everything can get in:
    At 18:04 22/05/2010, Pierre Joye wrote:

    hi Zeev,

    It seems that there was a bit of discussions on IRC about committing
    Ilia's implementation. However it is trunk, and trunk is a development
    tree. That means its purpose is to develop new PHP features. But it
    does not meant that these features will make it in the next releases
    or if they will remain as they are now.

    but when we start to roll out a release, laziness/eagerness kicks in, and we
    start rambling about status quo (if it's in the trunk, then its ready to
    go).
    On Sat, May 22, 2010 at 11:10 AM, Zeev Suraski wrote:

    Maybe I view trunk in a different way than others, but I think committing
    it turns it into some sort of 'status quo', and now we'd need a good reason
    to change it.
    And after all those discussion about the past and current scalar type hints,
    here they are: they are planned to be released, without consensus, and the
    current implementation doesn't even the same, that we talked our ass off
    about. :/

    5.4 should be hold off until we solved the listed issues and the
    release management RFC gets discussed and hopefully approved.
    Why do you need a release management RFC? We've made releases for more
    than a decade just fine.
    yeah, but the current situation is a little bit different(we have code in
    the trunk which was intended for 6.0, where bc isn't a problem at all), than
    the previous ones.
    and I think we can't say that there are room for improvements about the
    current "lackoff" release policies.
    hell, we don't even agree on things like what is the status of the code in
    trunk(can we commit without consensus, or do we decide about it before the
    release), or what are the rules for the versioning schema(which version is
    allowed to break what). :/

    Stalling every time doesn't get us anywhere. IMO we should just go with
    it.
    I am absolutely against stalling again!
    I am too, but I think that we should carefully cherrypick, what to release
    with 5.4 from the current trunk.

    Tyrael
  • Derick Rethans at Nov 23, 2010 at 1:58 pm

    On Tue, 23 Nov 2010, Ferenc Kovacs wrote:

    We also have no plan about what will or will not be 5.4. This looks
    familiar, this is exactly how we begun 5.3 and it tooks literally
    years to be released. There is also actually no agreement to begin
    with 5.4 now.
    Yes, but instead of defining "what is PHP 5.4", why not just go with
    what we have? Everything that's not in thre is for PHP-next-next again.
    backward compatibility™
    we had a few nice things in the PHP6 branch, which got merged into the
    trunk, before choosing the version number for the trunk.
    Do you have a list?
    Stalling every time doesn't get us anywhere. IMO we should just go with
    it.
    I am absolutely against stalling again!
    I am too, but I think that we should carefully cherrypick, what to release
    with 5.4 from the current trunk.
    Cherry pick? Do you have any idea how complicated that is?

    Derick
  • Zeev Suraski at Nov 23, 2010 at 11:24 am

    -----Original Message-----
    From: Derick Rethans
    Sent: Tuesday, November 23, 2010 11:58 AM
    To: Felipe Pena
    Cc: internals
    Subject: Re: [PHP-DEV] Hold off 5.4
    On Mon, 22 Nov 2010, Felipe Pena wrote:

    Given the current state of trunk, I think 5.4 release process should
    not begin tomorrow (alpha or whatever other status). There are
    numerous identified issues that we need to fix before even think to
    begin with a release. For example:

    - type hinting (or strict hinting)
    - no consensus
    - the RFCs are unclear
    - BC break introduced
    . classes named as any of the type hint scalar types do not work
    anymore aka class int {}
    Yeah, there is a slight hint of a BC break in case you have a class named "int"
    or "float" etc. But there is:
    http://uk.php.net/manual/en/userlandnaming.tips.php
    For the record, I'm still very uncomfortable with this new language syntax - even if it's a no-op right now.
    How do we document it? As what?
    Are we effectively going to create the original type checking implementation, but in a separate component people would have to install - thereby creating two very different flavors of PHP?

    Regarding the alpha release, I think there are two key issues here:

    1. Does this alpha mean anything at all. Some, myself included, don't feel comfortable about the state of certain things in the current codebase (example given above). Are we all in sync that even if a certain feature makes it into the alpha, it doesn't mean that it won't be removed or be severely modified in an upcoming beta/GA? Is it clear it has no implications on when the final release would be? That is, at least, the way I perceive alpha releases. In which case it's not exactly clear to me what the benefits of releasing an Alpha in this day and age for PHP - where we have snapshots every few hours. We need to have a very clear understanding of what this does or doesn't mean, and make sure we communicate it properly to the users.

    2. Not strictly related to this particular 5.4 effort, but I think that recent months have shown that we desperately need a decision making process. Somewhat more formalized and logical than anybody who happens to be subscribed to internals@ being able to put things to a vote and vote on them. This is one tough cookie - but I think we have to tackle it. My personal belief is that people on internals@ are biased towards the very top end of the userbase pyramid, and we have to find a way to represent the views of the PHP userbase at large.

    Zeev
  • Ferenc Kovacs at Nov 23, 2010 at 11:49 am
    On Tue, Nov 23, 2010 at 12:24 PM, Zeev Suraski wrote:
    -----Original Message-----
    From: Derick Rethans
    Sent: Tuesday, November 23, 2010 11:58 AM
    To: Felipe Pena
    Cc: internals
    Subject: Re: [PHP-DEV] Hold off 5.4
    On Mon, 22 Nov 2010, Felipe Pena wrote:

    Given the current state of trunk, I think 5.4 release process should
    not begin tomorrow (alpha or whatever other status). There are
    numerous identified issues that we need to fix before even think to
    begin with a release. For example:

    - type hinting (or strict hinting)
    - no consensus
    - the RFCs are unclear
    - BC break introduced
    . classes named as any of the type hint scalar types do not work
    anymore aka class int {}
    Yeah, there is a slight hint of a BC break in case you have a class named "int"
    or "float" etc. But there is:
    http://uk.php.net/manual/en/userlandnaming.tips.php
    For the record, I'm still very uncomfortable with this new language syntax
    - even if it's a no-op right now.
    How do we document it? As what?
    Johannes wrote a blogpost about that:
    http://schlueters.de/blog/archives/148-More-on-scalar-type-hints-in-PHP-trunk.html
    and we didn't even discussed the current implementations, because the
    discussion was halted until the new revised patch is complete.
    which seems will be rolled out without further discussion.

    Are we effectively going to create the original type checking
    implementation, but in a separate component people would have to install -
    thereby creating two very different flavors of PHP?

    Regarding the alpha release, I think there are two key issues here:

    1. Does this alpha mean anything at all. Some, myself included, don't
    feel comfortable about the state of certain things in the current codebase
    (example given above). Are we all in sync that even if a certain feature
    makes it into the alpha, it doesn't mean that it won't be removed or be
    severely modified in an upcoming beta/GA? Is it clear it has no
    implications on when the final release would be? That is, at least, the way
    I perceive alpha releases. In which case it's not exactly clear to me what
    the benefits of releasing an Alpha in this day and age for PHP - where we
    have snapshots every few hours. We need to have a very clear understanding
    of what this does or doesn't mean, and make sure we communicate it properly
    to the users.
    we shouldn't release something, that at least the core devs are agree on.
    imo.

    2. Not strictly related to this particular 5.4 effort, but I think that
    recent months have shown that we desperately need a decision making process.
    Somewhat more formalized and logical than anybody who happens to be
    subscribed to internals@ being able to put things to a vote and vote on
    them. This is one tough cookie - but I think we have to tackle it. My
    personal belief is that people on internals@ are biased towards the very
    top end of the userbase pyramid, and we have to find a way to represent the
    views of the PHP userbase at large.
    Agree.
    But I think that there are more than one kind of voting that we need.
    - what does the avarage php user thinks about something. (adding/removing a
    feature, who would use that, php.net redesign, etc.).
    - what does the cms/framework dev people think about something (there are
    many feature, which didn't useful directly to the end-users, but they can
    get good use of it through a framework: late static binding, namespaces,
    annotations, etc.)
    - what does our vendors think about something (debian, redhat, etc. they can
    provide useful feedback about configuration/maintenance, release policy kind
    of polls)
    - what does a php contributor(documentation, qa, website, etc. so involved
    in the php project) thinks about something (for example polls about our
    infrastructures, or standards, etc.)
    - what does a pecl contributor thinks about something (adding a new hook
    into the core, etc., changing internal API, etc.)
    - what does a php-src contributor thinks about something (hardcore stuff,
    adding new features by design/performance/maintainability wise, etc. )

    and maybe it would be a good idea to restrict the poll/vote for the active
    members.
    so if somebody was once involved in the project, but lost time or interest,
    and didn't followed or contributed to that part of the project, that those
    people to bias the vote without a good understanding about the actual
    problem/situation.

    but of course that's only my 2 cents.

    Tyrael
  • Derick Rethans at Nov 23, 2010 at 2:10 pm

    On Tue, 23 Nov 2010, Ferenc Kovacs wrote:

    and we didn't even discussed the current implementations, because the
    discussion was halted until the new revised patch is complete.
    which seems will be rolled out without further discussion.
    Really? You had all the opportunity to comment on either my
    announcement:
    http://thread.gmane.org/gmane.comp.php.devel/62298/focus=62510
    to which Dmitry and Stas commented; as well as my mail:
    http://thread.gmane.org/gmane.comp.php.devel/62298/focus=62858
    that annouced the third compromise implementation.

    cheers,
    Derick

    --
    http://derickrethans.nl | http://xdebug.org
    Like Xdebug? Consider a donation: http://xdebug.org/donate.php
    twitter: @derickr and @xdebug
  • Derick Rethans at Nov 23, 2010 at 2:04 pm

    On Tue, 23 Nov 2010, Zeev Suraski wrote:
    On Tue, 23 Nov 2010, Derick Rethans wrote:
    On Mon, 22 Nov 2010, Felipe Pena wrote:

    Given the current state of trunk, I think 5.4 release process should
    not begin tomorrow (alpha or whatever other status). There are
    numerous identified issues that we need to fix before even think to
    begin with a release. For example:

    - type hinting (or strict hinting)
    - no consensus
    - the RFCs are unclear
    - BC break introduced
    . classes named as any of the type hint scalar types do not work
    anymore aka class int {}
    Yeah, there is a slight hint of a BC break in case you have a class named "int"
    or "float" etc. But there is:
    http://uk.php.net/manual/en/userlandnaming.tips.php
    For the record, I'm still very uncomfortable with this new language
    syntax - even if it's a no-op right now.
    I know you are; but from what I understood, there were no more comments
    to the latest mail (with patch and RFC) that I've made towards this.

    I'm not comfortable about not having the proper strict checks that we
    had. It seems we're both having to live with something uncomfortable.
    Are we effectively going to create the original type checking
    implementation, but in a separate component people would have to
    install - thereby creating two very different flavors of PHP?
    It's clearly a debugging aid for me. So this should be in a debugging
    extension. I doubt any sort of shared hoster would install it, but it
    *does* give people the power to do this for their own controlled set-up.
    Also, if the extension is suddenly not there, the app will still work so
    I am not buying your "two flavours" argument.
    Regarding the alpha release, I think there are two key issues here:

    1. Does this alpha mean anything at all. Some, myself included,
    don't feel comfortable about the state of certain things in the
    current codebase (example given above). Are we all in sync that even
    if a certain feature makes it into the alpha, it doesn't mean that it
    won't be removed or be severely modified in an upcoming beta/GA?
    Is it clear it has no implications on when the final release would be?
    That is, at least, the way I perceive alpha releases. In which case
    it's not exactly clear to me what the benefits of releasing an Alpha
    in this day and age for PHP - where we have snapshots every few hours.
    We need to have a very clear understanding of what this does or
    doesn't mean, and make sure we communicate it properly to the users.
    To me this alpha would be a "this is what we're mostly likely going to
    have thing". I wouldn't like to see new major features, engine rework
    being done; but I also think we shouldn't try to remove stuff from it
    unless really necessary.

    regards,
    Derick

    --
    http://derickrethans.nl | http://xdebug.org
    Like Xdebug? Consider a donation: http://xdebug.org/donate.php
    twitter: @derickr and @xdebug
  • Matthew Weier O'Phinney at Nov 23, 2010 at 2:17 pm

    On 2010-11-23, Derick Rethans wrote:
    On Tue, 23 Nov 2010, Zeev Suraski wrote:
    Are we effectively going to create the original type checking
    implementation, but in a separate component people would have to
    install - thereby creating two very different flavors of PHP?
    It's clearly a debugging aid for me. So this should be in a debugging
    extension. I doubt any sort of shared hoster would install it, but it
    *does* give people the power to do this for their own controlled set-up.
    Also, if the extension is suddenly not there, the app will still work so
    I am not buying your "two flavours" argument.
    While the code may still work, it won't work *as* *expected*. If the
    PHP interpreter can execute the application, then it should provide the
    same output given the same input -- and this would not be the case.
    That's the two flavours argument.

    --
    Matthew Weier O'Phinney
    Project Lead | matthew@zend.com
    Zend Framework | http://framework.zend.com/
    PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
  • Derick Rethans at Nov 23, 2010 at 2:54 pm

    On Tue, 23 Nov 2010, Matthew Weier O'Phinney wrote:
    On 2010-11-23, Derick Rethans wrote:
    On Tue, 23 Nov 2010, Zeev Suraski wrote:
    Are we effectively going to create the original type checking
    implementation, but in a separate component people would have to
    install - thereby creating two very different flavors of PHP?
    It's clearly a debugging aid for me. So this should be in a
    debugging extension. I doubt any sort of shared hoster would install
    it, but it *does* give people the power to do this for their own
    controlled set-up. Also, if the extension is suddenly not there, the
    app will still work so I am not buying your "two flavours" argument.
    While the code may still work, it won't work *as* *expected*. If the
    PHP interpreter can execute the application, then it should provide the
    same output given the same input -- and this would not be the case.
    That's the two flavours argument.
    If it doesn't check for the hints, then your application will still
    work. I will say this once more: this is a *debugging* aid.

    cheers,
    Derick

    --
    http://derickrethans.nl | http://xdebug.org
    Like Xdebug? Consider a donation: http://xdebug.org/donate.php
    twitter: @derickr and @xdebug
  • Zeev Suraski at Nov 23, 2010 at 2:58 pm

    If it doesn't check for the hints, then your application will still work. I will say
    this once more: this is a *debugging* aid.
    If your app *relies* on it, then it means it will probably not use other means to ensure that the data is of the correct type, which may result in all sorts of issues.

    Zeev
  • Zeev Suraski at Nov 23, 2010 at 2:21 pm

    For the record, I'm still very uncomfortable with this new language
    syntax - even if it's a no-op right now.
    I know you are; but from what I understood, there were no more comments
    to the latest mail (with patch and RFC) that I've made towards this.
    I know, I took some time off after reaching agreement we're not going to add strict checks - but I said from the get go that it's questionable whether we should add this syntax.
    I'm not comfortable about not having the proper strict checks that we had.
    Except we never had them. It's like me committing support for inline assembly syntax or whatever other weird idea I might come up with, and then saying I don't feel comfortable about removing it. With such fundamental changes there should be a very broad support, with the status-quo being the default in case no such broad support is reached. The status quo is not the latest state of trunk, but rather, the state of previous versions.
    It seems we're both having to live with something uncomfortable.
    We should attribute as much importance to adding features as removing features; Can I jump ahead and remove this support in trunk, and get back to you with 'one of us will have to feel uncomfortable' feedback? I don't think it works that way. The status quo, and the way PHP existed since forever, is no strict type checking or syntax for supporting it. IMHO before there's a clear informed decision to change that, it should stay that way.

    With the kind of phpdoc updates we're likely to add, you should be able to implement your extension-level support on top of this meta data. The chances of that becoming mainstream and creating two flavors of PHP are much slimmer which make it a much better fit than a big chunk of language level syntax that's a no-op by default.
    Are we effectively going to create the original type checking
    implementation, but in a separate component people would have to
    install - thereby creating two very different flavors of PHP?
    It's clearly a debugging aid for me. So this should be in a debugging
    extension. I doubt any sort of shared hoster would install it, but it
    *does* give people the power to do this for their own controlled set-up.
    Also, if the extension is suddenly not there, the app will still work so I am not
    buying your "two flavours" argument.
    It may or may not work depending on how you write your code. If you rely on that feature your app may very well stop working properly (e.g. it may expose it to security issues).
    It's very much creating two flavors.
    Regarding the alpha release, I think there are two key issues here:

    1. Does this alpha mean anything at all. Some, myself included,
    don't feel comfortable about the state of certain things in the
    current codebase (example given above). Are we all in sync that even
    if a certain feature makes it into the alpha, it doesn't mean that it
    won't be removed or be severely modified in an upcoming beta/GA?
    Is it clear it has no implications on when the final release would be?
    That is, at least, the way I perceive alpha releases. In which case
    it's not exactly clear to me what the benefits of releasing an Alpha
    in this day and age for PHP - where we have snapshots every few hours.
    We need to have a very clear understanding of what this does or
    doesn't mean, and make sure we communicate it properly to the users.
    To me this alpha would be a "this is what we're mostly likely going to have
    thing". I wouldn't like to see new major features, engine rework being done;
    but I also think we shouldn't try to remove stuff from it unless really
    necessary.
    If that's the case, count me in those who oppose the release of the current codebase as an alpha.

    Zeev
  • Derick Rethans at Nov 23, 2010 at 2:56 pm

    On Tue, 23 Nov 2010, Zeev Suraski wrote:

    To me this alpha would be a "this is what we're mostly likely going
    to have thing". I wouldn't like to see new major features, engine
    rework being done; but I also think we shouldn't try to remove stuff
    from it unless really necessary.
    If that's the case, count me in those who oppose the release of the current codebase as an alpha.
    I find it interesting that apparently so many people don't want a new
    PHP version out, but forget to say what they think needs fixing. Instead
    of opposing, can we not do just some work?

    Derick

    --
    http://derickrethans.nl | http://xdebug.org
    Like Xdebug? Consider a donation: http://xdebug.org/donate.php
    twitter: @derickr and @xdebug
  • Zeev Suraski at Nov 23, 2010 at 2:57 pm

    I find it interesting that apparently so many people don't want a new PHP
    version out, but forget to say what they think needs fixing. Instead of
    opposing, can we not do just some work?
    Specifically the issue I'm most concerned about is the type hinting syntax.

    Zeev
  • Pierre Joye at Nov 25, 2010 at 1:15 am
    hi,
    hi,
    On Tue, Nov 23, 2010 at 3:56 PM, Derick Rethans wrote:
    On Tue, 23 Nov 2010, Zeev Suraski wrote:

    To me this alpha would be a "this is what we're mostly likely going
    to have thing". I wouldn't like to see new major features, engine
    rework being done; but I also think we shouldn't try to remove stuff
    from it unless really necessary.
    If that's the case, count me in those who oppose the release of the current codebase as an alpha.
    I find it interesting that apparently so many people don't want a new
    PHP version out, but forget to say what they think needs fixing. Instead
    of opposing, can we not do just some work?
    I do want a new PHP release. I do want a clear, transparent, honest
    process to decide which features get in, to select the release
    managers and to get the release out.

    It also happens that I do some work as well.

    Cheers,
  • Michael Wallner at Nov 23, 2010 at 12:40 pm

    On 11/23/2010 10:57 AM, Derick Rethans wrote:
    On Mon, 22 Nov 2010, Felipe Pena wrote:

    - pecl/http was planned to be bundled. What's the status?
    I'm all for it; but again, it's just copying it over to trunk before we
    branch. ...
    - copy over APC/pecl_http
    - branch on thursday
    - alpha next week
    - build a list of things that needs doing in 5.4 to get it ready (with
    possible options to get rid of apc/pecl_http if they are not up to
    date enough)
    Huh? I'm quite surprised to read that pecl/http is planned to be bundled
    with trunk, while--sure--my grand master plan included this option, there's
    only pecl/http/branches/DEV_2 which is compatible with trunk and I doubt
    you all are talking about that version?

    It still needs some serious amount of work, development has stalled again
    due to my job's demands.

    Cheers, Mike
  • Derick Rethans at Nov 23, 2010 at 1:53 pm

    On Tue, 23 Nov 2010, Michael Wallner wrote:
    On 11/23/2010 10:57 AM, Derick Rethans wrote:
    On Mon, 22 Nov 2010, Felipe Pena wrote:

    - pecl/http was planned to be bundled. What's the status?
    I'm all for it; but again, it's just copying it over to trunk before we
    branch. ...
    - copy over APC/pecl_http
    - branch on thursday
    - alpha next week
    - build a list of things that needs doing in 5.4 to get it ready (with
    possible options to get rid of apc/pecl_http if they are not up to
    date enough)
    Huh? I'm quite surprised to read that pecl/http is planned to be bundled
    with trunk, while--sure--my grand master plan included this option, there's
    only pecl/http/branches/DEV_2 which is compatible with trunk and I doubt
    you all are talking about that version?
    Nope; I wasn't. But fine then, we don't bundle it :-)

    Derick

    --
    http://derickrethans.nl | http://xdebug.org
    Like Xdebug? Consider a donation: http://xdebug.org/donate.php
    twitter: @derickr and @xdebug
  • Ilia Alshanetsky at Nov 23, 2010 at 6:22 pm
    I too must second Mike's comments about pecl_http not being quite
    ready for bundling. The extension provides some useful functionality,
    no doubt (I use it ;-)). But I don't think there is a good case for
    bundling it.
    On Tue, Nov 23, 2010 at 7:40 AM, Michael Wallner wrote:
    On 11/23/2010 10:57 AM, Derick Rethans wrote:
    On Mon, 22 Nov 2010, Felipe Pena wrote:

    - pecl/http was planned to be bundled. What's the status?
    I'm all for it; but again, it's just copying it over to trunk before we
    branch. ...
    - copy over APC/pecl_http
    - branch on thursday
    - alpha next week
    - build a list of things that needs doing in 5.4 to get it ready (with
    possible options to get rid of apc/pecl_http if they are not up to
    date enough)
    Huh?  I'm quite surprised to read that pecl/http is planned to be bundled
    with trunk, while--sure--my grand master plan included this option, there's
    only pecl/http/branches/DEV_2 which is compatible with trunk and I doubt
    you all are talking about that version?

    It still needs some serious amount of work, development has stalled again
    due to my job's demands.

    Cheers, Mike

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
  • Matthew Weier O'Phinney at Nov 23, 2010 at 2:06 pm

    On 2010-11-23, Derick Rethans wrote:
    On Mon, 22 Nov 2010, Felipe Pena wrote:
    . classes named as any of the type hint scalar types
    do not work anymore
    aka class int {}
    Yeah, there is a slight hint of a BC break in case you have a class
    named "int" or "float" etc. But there is:
    http://uk.php.net/manual/en/userlandnaming.tips.php

    Perhaps we can reduce the current list of classes:
    int, integer, real, double, string, binary, scalar, array, object,
    bool, boolean
    to what the manual uses though (for prototypes):
    int, float, string, binary, scalar, array, object, bool
    (Point #18 at http://doc.php.net/php/dochowto/chapter-conventions.php)
    Sorry, but this is actually a pretty grave BC break.

    Currently, you can do the following:

    namespace Foo\Validator;

    class Int {}

    Because of the changes proposed, this would no longer work, breaking
    code that currently works with 5.3. I'd only expect a break like this
    when jumping to a major version -- and even then, I'd think that adding
    new keywords for such common names would need a *lot* of justification.

    As Sebastian noted, it seems this should be addressed with the new
    lexer; I'd argue that if the current type hinting must introduce new
    keywords, it should wait until the new lexer is in place in order to
    insulate end-users from such changes.

    <snip>
    We also have no plan about what will or will not be 5.4. This looks
    familiar, this is exactly how we begun 5.3 and it tooks literally
    years to be released. There is also actually no agreement to begin
    with 5.4 now.
    Yes, but instead of defining "what is PHP 5.4", why not just go with
    what we have? Everything that's not in thre is for PHP-next-next again.
    5.4 should be hold off until we solved the listed issues and the
    release management RFC gets discussed and hopefully approved.
    Why do you need a release management RFC? We've made releases for more
    than a decade just fine.

    Stalling every time doesn't get us anywhere. IMO we should just go with
    it. Which means as a rough guide:

    - copy over APC/pecl_http
    - branch on thursday
    - alpha next week
    - build a list of things that needs doing in 5.4 to get it ready (with
    possible options to get rid of apc/pecl_http if they are not up to
    date enough)

    I am absolutely against stalling again!
    I call shenanigans. This is *exactly* why a release process is desired
    and necessary -- because right now, there are BC breaks in trunk, only a
    vague idea about what may or may not be ready, and competing ideas about
    what constitutes grounds for branching. "Just go with it" may work for a
    few people, but that sort of attitude leaves those whose features were
    skipped over or who were away from the list and/or IRC for a few days
    wondering what happened later. With a defined release process,
    *everyone* knows what must be done, by when, making the process more
    transparent and *gasp* democratic.

    --
    Matthew Weier O'Phinney
    Project Lead | matthew@zend.com
    Zend Framework | http://framework.zend.com/
    PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
  • Derick Rethans at Nov 23, 2010 at 2:53 pm

    On Tue, 23 Nov 2010, Matthew Weier O'Phinney wrote:
    On 2010-11-23, Derick Rethans wrote:
    On Mon, 22 Nov 2010, Felipe Pena wrote:
    . classes named as any of the type hint scalar types
    do not work anymore
    aka class int {}
    Yeah, there is a slight hint of a BC break in case you have a class
    named "int" or "float" etc. But there is:
    http://uk.php.net/manual/en/userlandnaming.tips.php

    Perhaps we can reduce the current list of classes:
    int, integer, real, double, string, binary, scalar, array, object,
    bool, boolean
    to what the manual uses though (for prototypes):
    int, float, string, binary, scalar, array, object, bool
    (Point #18 at http://doc.php.net/php/dochowto/chapter-conventions.php)
    Sorry, but this is actually a pretty grave BC break.

    Currently, you can do the following:

    namespace Foo\Validator;

    class Int {}
    During our namespace discussion, this is exactly what I warned about. In
    order to make use of namespaces, you need to have atleast two "elements"
    in your class names otherwise we can still never introduce a new class.
    But that was not listened too.
    As Sebastian noted, it seems this should be addressed with the new
    lexer; I'd argue that if the current type hinting must introduce new
    keywords, it should wait until the new lexer is in place in order to
    insulate end-users from such changes.
    The new lexer however, is a slower; so not a viable solution right now.
    With a defined release process, *everyone* knows what must be done, by
    when, making the process more transparent and *gasp* democratic.
    Well, I don't think we've ever been democratic. I probably think
    that that wouldn't even work. Also, I think an alpha has pretty much
    been announce nicely on time for people to know what's happening.

    Derick

    --
    http://derickrethans.nl | http://xdebug.org
    Like Xdebug? Consider a donation: http://xdebug.org/donate.php
    twitter: @derickr and @xdebug
  • Stas Malyshev at Nov 23, 2010 at 9:27 pm
    Hi!
    During our namespace discussion, this is exactly what I warned about. In
    order to make use of namespaces, you need to have atleast two "elements"
    in your class names otherwise we can still never introduce a new class.
    But that was not listened too.
    I'm not sure I understand this point, could you explain?
    --
    Stanislav Malyshev, Software Architect
    SugarCRM: http://www.sugarcrm.com/
    (408)454-6900 ext. 227
  • André Rømcke at Nov 24, 2010 at 12:42 pm

    On Tue, Nov 23, 2010 at 3:53 PM, Derick Rethans wrote:
    On Tue, 23 Nov 2010, Matthew Weier O'Phinney wrote:
    On 2010-11-23, Derick Rethans wrote:
    On Mon, 22 Nov 2010, Felipe Pena wrote:
    . classes named as any of the type hint scalar types
    do not work anymore
    aka class int {}
    Yeah, there is a slight hint of a BC break in case you have a class
    named "int" or "float" etc. But there is:
    http://uk.php.net/manual/en/userlandnaming.tips.php

    Perhaps we can reduce the current list of classes:
    int, integer, real, double, string, binary, scalar, array, object,
    bool, boolean
    to what the manual uses though (for prototypes):
    int, float, string, binary, scalar, array, object, bool
    (Point #18 at http://doc.php.net/php/dochowto/chapter-conventions.php)
    Sorry, but this is actually a pretty grave BC break.

    Currently, you can do the following:

    namespace Foo\Validator;

    class Int {}
    During our namespace discussion, this is exactly what I warned about. In
    order to make use of namespaces, you need to have atleast two "elements"
    in your class names otherwise we can still never introduce a new class.
    But that was not listened too.
    As Sebastian noted, it seems this should be addressed with the new
    lexer; I'd argue that if the current type hinting must introduce new
    keywords, it should wait until the new lexer is in place in order to
    insulate end-users from such changes.
    The new lexer however, is a slower; so not a viable solution right now.
    With a defined release process, *everyone* knows what must be done, by
    when, making the process more transparent and *gasp* democratic.
    Well, I don't think we've ever been democratic. I probably think
    that that wouldn't even work. Also, I think an alpha has pretty much
    been announce nicely on time for people to know what's happening.


    I think what Matthew suggest here is something in the line of democratically
    defining a release process up front: features you would like to get in (a
    roadmap that clearly states that the content can change up until a feature
    freeze), a deadline for the feature freeze so that the process is
    predictable and appoint a release manager to be in charge of the branch.

    Something like:
    - Branching next version from day one so you have one called next and one
    called trunk for edge stuff, and appoint a release manager to approve
    features as they are merged from development branch(es)
    Alternatively (among several possible branch strategies) in DVCS you could
    use topic branches for the edge implementations, this is cleaner (maybe),
    but the point is to have a release branch that can be stabilized at anytime.
    For a more in-depth branching possibility see:
    http://nvie.com/posts/a-successful-git-branching-model/

    - Define a feature freeze date, anything not ready feature or stability wise
    is moved to Next Next roadmap (they are not in the Next release branch
    anyway as it only has feature complete features at any point)
    And branch off Next Next and appoint a release manager for that branch so
    there is always an active release branch.

    This will give a more predictable release schedule for everyone involved,
    especially for php users as it will give them a real hint on when the
    testing process of the next version will begin and some clue on when it
    might get finalized. All without having to introduce full fledge scrum and /
    or a strict release process.


    - ar
  • André Rømcke at Nov 24, 2010 at 12:43 pm

    On Wed, Nov 24, 2010 at 1:41 PM, André Rømcke wrote:
    On Tue, Nov 23, 2010 at 3:53 PM, Derick Rethans wrote:
    On Tue, 23 Nov 2010, Matthew Weier O'Phinney wrote:
    On 2010-11-23, Derick Rethans wrote:
    On Mon, 22 Nov 2010, Felipe Pena wrote:
    . classes named as any of the type hint scalar types
    do not work anymore
    aka class int {}
    Yeah, there is a slight hint of a BC break in case you have a class
    named "int" or "float" etc. But there is:
    http://uk.php.net/manual/en/userlandnaming.tips.php

    Perhaps we can reduce the current list of classes:
    int, integer, real, double, string, binary, scalar, array, object,
    bool, boolean
    to what the manual uses though (for prototypes):
    int, float, string, binary, scalar, array, object, bool
    (Point #18 at http://doc.php.net/php/dochowto/chapter-conventions.php
    )
    Sorry, but this is actually a pretty grave BC break.

    Currently, you can do the following:

    namespace Foo\Validator;

    class Int {}
    During our namespace discussion, this is exactly what I warned about. In
    order to make use of namespaces, you need to have atleast two "elements"
    in your class names otherwise we can still never introduce a new class.
    But that was not listened too.
    As Sebastian noted, it seems this should be addressed with the new
    lexer; I'd argue that if the current type hinting must introduce new
    keywords, it should wait until the new lexer is in place in order to
    insulate end-users from such changes.
    The new lexer however, is a slower; so not a viable solution right now.
    With a defined release process, *everyone* knows what must be done, by
    when, making the process more transparent and *gasp* democratic.
    Well, I don't think we've ever been democratic. I probably think
    that that wouldn't even work. Also, I think an alpha has pretty much
    been announce nicely on time for people to know what's happening.


    I think what Matthew suggest here is something in the line of
    democratically defining a release process up front: features you would like
    to get in (a roadmap that clearly states that the content can change up
    until a feature freeze), a deadline for the feature freeze so that the
    process is predictable and appoint a release manager to be in charge of the
    branch.

    Something like:
    - Branching next version from day one so you have one called next and one
    called trunk for edge stuff, and appoint a release manager to approve
    features as they are merged from development branch(es)
    Alternatively (among several possible branch strategies) in DVCS you could
    use topic branches for the edge implementations, this is cleaner (maybe),
    but the point is to have a release branch that can be stabilized at anytime.
    For a more in-depth branching possibility see:
    http://nvie.com/posts/a-successful-git-branching-model/

    - Define a feature freeze date, anything not ready feature or stability
    wise is moved to Next Next roadmap (they are not in the Next release branch
    anyway as it only has feature complete features at any point)
    And branch off Next Next and appoint a release manager for that branch so
    there is always an active release branch.
    When feature freeze date for Next is reached.

    This will give a more predictable release schedule for everyone involved,
    especially for php users as it will give them a real hint on when the
    testing process of the next version will begin and some clue on when it
    might get finalized. All without having to introduce full fledge scrum and /
    or a strict release process.


    - ar
  • Pierre Joye at Nov 25, 2010 at 1:18 am
    hi,
    On Tue, Nov 23, 2010 at 3:53 PM, Derick Rethans wrote:

    Well, I don't think we've ever been democratic.
    Neither have we been dictatorial. Announcing a new major (x.y+1.z)
    release in the middle of some of the largest conferences (knowing that
    many core devs won't follow the list) and for a couple of weeks later
    was not the best thing to do. To commit something that did not get any
    consensus and then force us to go out with a release is bad.
  • Pierre Joye at Nov 25, 2010 at 1:13 am
    hi Derick,
    On Tue, Nov 23, 2010 at 10:57 AM, Derick Rethans wrote:

    I am absolutely against stalling again!
    I am absolutely against going into a release process with the current
    state of the affairs.

    I think it would be much better for everyone if we first agree on the
    release process RFC, including the selection of the release managers,
    the features inclusions and the BC breaks policy.

    Last but not least, I don't think the type hinting (or strict typing)
    got any agreement or go any approved RFC. That alone is a no-go for a
    release.

    Cheers,
  • Michael Wallner at Nov 23, 2010 at 12:41 pm

    On 11/23/2010 02:30 AM, Felipe Pena wrote:
    Given the current state of trunk, I think 5.4 release process should
    not begin tomorrow (alpha or whatever other status). There are
    numerous identified issues that we need to fix before even think to
    begin with a release. For example: ...
    We also have no plan about what will or will not be 5.4. This looks
    familiar, this is exactly how we begun 5.3 and it tooks literally
    years to be released. There is also actually no agreement to begin
    with 5.4 now.

    5.4 should be hold off until we solved the listed issues and the
    release management RFC gets discussed and hopefully approved.
    +1
  • Pierre Joye at Nov 25, 2010 at 1:29 am

    On Tue, Nov 23, 2010 at 1:41 PM, Michael Wallner wrote:
    On 11/23/2010 02:30 AM, Felipe Pena wrote:

    5.4 should be hold off until we solved the listed issues and the
    release management RFC gets discussed and hopefully approved.
    +1
    +1 here too.
  • Davey Shafik at Nov 25, 2010 at 7:16 am

    On Nov 24, 2010, at 8:29 PM, Pierre Joye wrote:
    On Tue, Nov 23, 2010 at 1:41 PM, Michael Wallner wrote:
    On 11/23/2010 02:30 AM, Felipe Pena wrote:

    5.4 should be hold off until we solved the listed issues and the
    release management RFC gets discussed and hopefully approved.
    The reality is that trunk is not going to be 5.4; it cannot be in its current state.

    The reason behind ditching the unicode php6 was to enable innovation in trunk. This meant
    we could have traits, type hinting, apc in core etc, as well as internal enhancements, the new lemon
    parser etc. Regardless of the arguments and unresolved issues, this IS happening, and IS a good thing.

    The goal then was to essentially take the 5.3 branch, create a 5.4 branch, cherry pick commits to trunk
    and apply them to the 5.4 branch and end up with a stable build. Unfortunately, subversion merging sucks.

    This is an unreliable, laborious, crappy method for creating stable branches, and managing the
    repo. Worse yet, SVN's merge-tracking/branch reintegration also sucks, so creating feature branches and
    re-integrating is also a pretty crappy solution.

    So, with the BC breaks committed to trunk (register globals) or that we want to commit to trunk (magic quotes), as
    well as the code without consensus, creating a stable 5.4 branch is going to be a lot of work.

    Now, I'm no advocate of git (I've yet to jump on the bandwagon for my main repo, but have several small projects on
    github), but it seems that it's capabilities would make these things much more trivial. Obviously: not a solution for now.

    We need to get our repo in order first, then we can start talking about 5.4. The RMs need to make a definitive
    stand about how the repo will be managed, and explain to us how that's going to trickle down to our personal habits.

    This doesn't seem the ideal time to introduce a new toolchain, so sticking with SVN, we should maintain 4 branches, 5.2 (security only), 5.3 (bug fixes + security), 5.4 (agreed upon enhancements, no BC breaks), 6.0 (BC breaks).

    Non-agreed upon enhancements, potential BC breaks, all should be done in feature branches. This gives people buildable
    (hopefully) branches to use for testing, revision control for those developing the features, and unmuddied commit histories
    to more easily pull those changes into the appropriate branches.

    - Davey
  • Patrick ALLAERT at Nov 25, 2010 at 7:49 am
    2010/11/25 Davey Shafik <davey@php.net>:
    On Nov 24, 2010, at 8:29 PM, Pierre Joye wrote:
    On Tue, Nov 23, 2010 at 1:41 PM, Michael Wallner wrote:
    On 11/23/2010 02:30 AM, Felipe Pena wrote:

    5.4 should be hold off until we solved the listed issues and the
    release management RFC gets discussed and hopefully approved.
    The reality is that trunk is not going to be 5.4; it cannot be in its current state.

    The reason behind ditching the unicode php6 was to enable innovation in trunk. This meant
    we could have traits, type hinting, apc in core etc, as well as internal enhancements, the new lemon
    parser etc. Regardless of the arguments and unresolved issues, this IS happening, and IS a good thing.

    The goal then was to essentially take the 5.3 branch, create a 5.4 branch, cherry pick commits to trunk
    and apply them to the 5.4 branch and end up with a stable build. Unfortunately, subversion merging sucks.

    This is an unreliable, laborious, crappy method for creating stable branches, and managing the
    repo. Worse yet, SVN's merge-tracking/branch reintegration also sucks, so creating feature branches and
    re-integrating is also a pretty crappy solution.

    So, with the BC breaks committed to trunk (register globals) or that we want to commit to trunk (magic quotes), as
    well as the code without consensus, creating a stable 5.4 branch is going to be a lot of work.

    Now, I'm no advocate of git (I've yet to jump on the bandwagon for my main repo, but have several small projects on
    github), but it seems that it's capabilities would make these things much more trivial. Obviously: not a solution for now.

    We need to get our repo in order first, then we can start talking about 5.4. The RMs need to make a definitive
    stand about how the repo will be managed, and explain to us how that's going to trickle down to our personal habits.

    This doesn't seem the ideal time to introduce a new toolchain, so sticking with SVN, we should  maintain 4 branches, 5.2 (security only), 5.3 (bug fixes + security), 5.4 (agreed upon enhancements, no BC breaks), 6.0 (BC breaks).

    Non-agreed upon enhancements, potential BC breaks, all should be done in feature branches. This gives people buildable
    (hopefully) branches to use for testing, revision control for those developing the features, and unmuddied commit histories
    to more easily pull those changes into the appropriate branches.

    - Davey
    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
    I think Davey has a clear view and a good explanation about the
    current situation.
    Trunk has been used for both short and long term development hence the
    difficulties to agree that trunk is about 5.4 or +.

    In a first place, we should decide on what to have for 5.4 and what to
    leave for the future.

    A technical way to do it would be to use git-svn locally, starting
    from the PHP_5_3 branch and merging it with trunk. git rebase -i can
    then be used easily to remove all the commits we don't want to appear
    in 5.4.

    --
    Patrick
  • Jani Taskinen at Nov 25, 2010 at 8:24 am
    Who says it has to be 5.4? People seem to be a bit fixated on the version there.
    Major BC breaks just means the version released from trunk is 6.0. And it's just a number. Big number, but still just a number.

    Merging (by and or by magic :) features into branch created from 5.3 just sounds like plane crash waiting to happen..

    ---Jani


    On Nov 25, 2010, at 9:16 AM, Davey Shafik wrote:

    On Nov 24, 2010, at 8:29 PM, Pierre Joye wrote:
    On Tue, Nov 23, 2010 at 1:41 PM, Michael Wallner wrote:
    On 11/23/2010 02:30 AM, Felipe Pena wrote:

    5.4 should be hold off until we solved the listed issues and the
    release management RFC gets discussed and hopefully approved.
    The reality is that trunk is not going to be 5.4; it cannot be in its current state.

    The reason behind ditching the unicode php6 was to enable innovation in trunk. This meant
    we could have traits, type hinting, apc in core etc, as well as internal enhancements, the new lemon
    parser etc. Regardless of the arguments and unresolved issues, this IS happening, and IS a good thing.

    The goal then was to essentially take the 5.3 branch, create a 5.4 branch, cherry pick commits to trunk
    and apply them to the 5.4 branch and end up with a stable build. Unfortunately, subversion merging sucks.

    This is an unreliable, laborious, crappy method for creating stable branches, and managing the
    repo. Worse yet, SVN's merge-tracking/branch reintegration also sucks, so creating feature branches and
    re-integrating is also a pretty crappy solution.

    So, with the BC breaks committed to trunk (register globals) or that we want to commit to trunk (magic quotes), as
    well as the code without consensus, creating a stable 5.4 branch is going to be a lot of work.

    Now, I'm no advocate of git (I've yet to jump on the bandwagon for my main repo, but have several small projects on
    github), but it seems that it's capabilities would make these things much more trivial. Obviously: not a solution for now.

    We need to get our repo in order first, then we can start talking about 5.4. The RMs need to make a definitive
    stand about how the repo will be managed, and explain to us how that's going to trickle down to our personal habits.

    This doesn't seem the ideal time to introduce a new toolchain, so sticking with SVN, we should maintain 4 branches, 5.2 (security only), 5.3 (bug fixes + security), 5.4 (agreed upon enhancements, no BC breaks), 6.0 (BC breaks).

    Non-agreed upon enhancements, potential BC breaks, all should be done in feature branches. This gives people buildable
    (hopefully) branches to use for testing, revision control for those developing the features, and unmuddied commit histories
    to more easily pull those changes into the appropriate branches.

    - Davey
    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
  • Patrick ALLAERT at Nov 25, 2010 at 11:46 am

    2010/11/25 Jani Taskinen <jani.taskinen@iki.fi>:
    Who says it has to be 5.4? People seem to be a bit fixated on the version there.
    I'd like to know too...
    Major BC breaks just means the version released from trunk is 6.0. And it's just a number. Big number, but still just a number.
    Well, such a change tends to create a big buzz, without mentioning
    stuff like certifications, trainings,...

    We should avoid creating a virtual PHP 6.0 which will contain all the
    BC stuff while all features appears in 5.x.
    By doing so we will keep some shit in 5.x forever and won't have
    anything appealing enough to migrate to 6.0!
    Merging (by and or by magic :) features into branch created from 5.3 just sounds like plane crash waiting to happen..

    ---Jani
  • Jani Taskinen at Nov 25, 2010 at 12:47 pm

    On Nov 25, 2010, at 1:46 PM, Patrick ALLAERT wrote:

    2010/11/25 Jani Taskinen <jani.taskinen@iki.fi>:
    Who says it has to be 5.4? People seem to be a bit fixated on the version there.
    I'd like to know too...
    Major BC breaks just means the version released from trunk is 6.0. And it's just a number. Big number, but still just a number.
    Well, such a change tends to create a big buzz, without mentioning
    stuff like certifications, trainings,...
    This is a joke, right?
    We should avoid creating a virtual PHP 6.0 which will contain all the
    BC stuff while all features appears in 5.x.
    By doing so we will keep some shit in 5.x forever and won't have
    anything appealing enough to migrate to 6.0
    ..or have something really new and interesting in PHP 7.0.0. The big version number change is reserved for BC changing stuff, not just for "fancy new stuff".

    --Jani
  • James Butler at Nov 25, 2010 at 12:58 pm
    Slightly brambly thoughts...
    I think (imho) the PHP6 hype in user land died down long ago after it became obvious it wouldn't materialise any time soon. It would be nice to see 6 to appear if only to break the (apparent) deadlock that the Unicode stuff brought on(I realise this is not enough justification by itself)
    What will this mean to all the Hosting providers etc who are still finishing long running 4->5 or 5.x -> 5.3 migrations? Will they resist change more because it looks like a bigger change regardless of the underlying code? As they provide installs/hosting for what I can guess to be a huge amount of the PHP's actual users is it factor that's worth considering

    I realise this is a Friday afternoon category comment but it can't wait..
    Think of all of those PHP6 books that will be reduced to near junk status in swift branch/commit action
    And as a bonus

    -----Original Message-----
    From: Jani Taskinen
    On Nov 25, 2010, at 1:46 PM, Patrick ALLAERT wrote:

    2010/11/25 Jani Taskinen <jani.taskinen@iki.fi>:
    Who says it has to be 5.4? People seem to be a bit fixated on the version there.
    I'd like to know too...
    Major BC breaks just means the version released from trunk is 6.0. And it's just a number. Big number, but still just a number.
    Well, such a change tends to create a big buzz, without mentioning
    stuff like certifications, trainings,...
    This is a joke, right?
    We should avoid creating a virtual PHP 6.0 which will contain all the
    BC stuff while all features appears in 5.x.
    By doing so we will keep some shit in 5.x forever and won't have
    anything appealing enough to migrate to 6.0
    ..or have something really new and interesting in PHP 7.0.0. The big version number change is reserved for BC changing stuff, not just for "fancy new stuff".

    --Jani
  • Pierre Joye at Nov 25, 2010 at 1:02 pm
    May I ask not to begin with that again? The php 2034 thing?

    Let sort out what has to be sorted out, like the current proposals. In
    the short term, a 5.x (with BC) is what users and developers are
    looking for. We can then begin to think about the next big step.

    On Thu, Nov 25, 2010 at 1:58 PM, James Butler
    wrote:
    Slightly brambly thoughts...
    I think (imho) the PHP6 hype in user land died down long ago after it became obvious it wouldn't materialise any time soon. It would be nice to see 6 to appear if only to break the (apparent) deadlock that the Unicode stuff brought on(I realise this is not enough justification by itself)
    What will this mean to all the Hosting providers etc who are still finishing long running 4->5 or  5.x -> 5.3 migrations? Will they resist change more because it looks like a bigger change regardless of the underlying code? As they provide installs/hosting for what I can guess to be a huge amount of the PHP's actual users is it factor that's worth considering

    I realise this is a Friday afternoon category comment but it can't wait..
    Think of all of those PHP6 books that will be reduced to near junk status in swift branch/commit action
    And as a bonus

    -----Original Message-----
    From: Jani Taskinen
    On Nov 25, 2010, at 1:46 PM, Patrick ALLAERT wrote:

    2010/11/25 Jani Taskinen <jani.taskinen@iki.fi>:
    Who says it has to be 5.4? People seem to be a bit fixated on the version there.
    I'd like to know too...
    Major BC breaks just means the version released from trunk is 6.0. And it's just a number. Big number, but still just a number.
    Well, such a change tends to create a big buzz, without mentioning
    stuff like certifications, trainings,...
    This is a joke, right?
    We should avoid creating a virtual PHP 6.0 which will contain all the
    BC stuff while all features appears in 5.x.
    By doing so we will keep some shit in 5.x forever and won't have
    anything appealing enough to migrate to 6.0
    ..or have something really new and interesting in PHP 7.0.0. The big version number change is reserved for BC changing stuff, not just for "fancy new stuff".

    --Jani



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


    --
    Pierre

    @pierrejoye | http://blog.thepimp.net | http://www.libgd.org
  • Andi Gutmans at Nov 25, 2010 at 5:11 pm

    -----Original Message-----
    From: Jani Taskinen
    Sent: Thursday, November 25, 2010 12:25 AM
    To: davey@php.net
    Cc: PHP Internals
    Subject: Re: [PHP-DEV] Re: Hold off 5.4

    Who says it has to be 5.4? People seem to be a bit fixated on the version there.
    Major BC breaks just means the version released from trunk is 6.0. And it's just
    a number. Big number, but still just a number.

    Merging (by and or by magic :) features into branch created from 5.3 just
    sounds like plane crash waiting to happen..
    I agree and I don't think we're in as bad shape although there's some cleaning up that needs to be done.
    For what it's worth the changes we've made in the Zend Engine around performance and memory use could warrant a major version. Every major version of PHP in the past has been driven foremost by major engine overhauls. I believe there's quite a bit more that we can do during the pre-beta phase in these areas to strengthen that and those changes with a combination of traits, some cleanup of deprecated e.g. safe_mode could warrant a major new version.
    If we do go down that route I would advocate calling it PHP 7 and not PHP 6, not because I like jumping ahead so far (I don't like I am sure most people here don't) but we don't want people to search for PHP 6 and find past information which is not relevant to this version we release. Then again I can live with it either way but we should be aware of the negative implications there could be.

    Andi
  • Johannes Schlüter at Nov 25, 2010 at 5:21 pm

    On Thu, 2010-11-25 at 17:11 +0000, Andi Gutmans wrote:
    For what it's worth the changes we've made in the Zend Engine around
    performance and memory use could warrant a major version. Every major
    version of PHP in the past has been driven foremost by major engine
    overhauls.
    Yes, larger changes to the engine changed the major number. But all of
    them had a big effect. This is "only" performance. No functionality. 90%
    of the users won't notice it. Whereas everbody oticed the change from3
    to 4 or the new object model in 5. Changing the major number has two big
    effects: a) marketing b) more fear for doing the upgrade.

    I value b) as the more relevant factor to monitor.

    johannes
  • Rasmus Lerdorf at Nov 25, 2010 at 5:27 pm

    On 11/25/10 9:20 AM, Johannes Schlüter wrote:
    On Thu, 2010-11-25 at 17:11 +0000, Andi Gutmans wrote:
    For what it's worth the changes we've made in the Zend Engine around
    performance and memory use could warrant a major version. Every major
    version of PHP in the past has been driven foremost by major engine
    overhauls.
    Yes, larger changes to the engine changed the major number. But all of
    them had a big effect. This is "only" performance. No functionality. 90%
    of the users won't notice it. Whereas everbody oticed the change from3
    to 4 or the new object model in 5. Changing the major number has two big
    effects: a) marketing b) more fear for doing the upgrade.

    I value b) as the more relevant factor to monitor.
    Looking through trunk I think we are in pretty good shape. I don't
    think cherry-picking and branch merging is an issue at this point. A
    5.4 with the performance improvements, Traits, minus the type hinting
    breakage is something we can get out pretty quickly without causing any
    sort of PHP 6 confusion or breaking existing apps.

    -Rasmus
  • Pierre Joye at Nov 25, 2010 at 5:38 pm
    hi Rasmus,

    2010/11/25 Rasmus Lerdorf <rasmus@lerdorf.com>:
    On 11/25/10 9:20 AM, Johannes Schlüter wrote:
    On Thu, 2010-11-25 at 17:11 +0000, Andi Gutmans wrote:
    For what it's worth the changes we've made in the Zend Engine around
    performance and memory use could warrant a major version. Every major
    version of PHP in the past has been driven foremost by major engine
    overhauls.
    Yes, larger changes to the engine changed the major number. But all of
    them had a big effect. This is "only" performance. No functionality. 90%
    of the users won't notice it. Whereas everbody oticed the change from3
    to 4 or the new object model in 5. Changing the major number has two big
    effects: a) marketing b) more fear for doing the upgrade.

    I value b) as the more relevant factor to monitor.
    Looking through trunk I think we are in pretty good shape.  I don't
    think cherry-picking and branch merging is an issue at this point.  A
    5.4 with the performance improvements, Traits, minus the type hinting
    breakage is something we can get out pretty quickly without causing any
    sort of PHP 6 confusion or breaking existing apps.
    Agreed, a php6 now just does not make sense, no matter from which point of view.

    I would not define 5.4 as being in a good shape but in a very
    promising shape to prepare a release. Removing the breakage, do some
    clear review of what we have (from a BC pov for one) and we could
    begin with a 5.4 release. However let get the RFC sorted out first
    before (it seems that we clearly have a consensus on most parts, time
    lines need to be adapted to avoid 5 releases at the same time :).

    Indeed, the type hint patch should be reverted as well, the sooner the better.

    Cheers,
  • Andi Gutmans at Nov 25, 2010 at 5:43 pm

    -----Original Message-----
    From: Rasmus Lerdorf
    Sent: Thursday, November 25, 2010 9:27 AM
    To: Johannes Schlüter
    Cc: Andi Gutmans; Jani Taskinen; davey@php.net; PHP Internals
    Subject: Re: [PHP-DEV] Re: Hold off 5.4

    Looking through trunk I think we are in pretty good shape. I don't think cherry-
    picking and branch merging is an issue at this point. A
    5.4 with the performance improvements, Traits, minus the type hinting
    breakage is something we can get out pretty quickly without causing any sort of
    PHP 6 confusion or breaking existing apps.

    Btw, just to be clear I am also OK with this approach. I just wanted to make sure we consider the pros/cons of doing minor vs. major so we're all aligned re: the implications :) I would pass on any type hinting patch because there's no consensus and if we rip it out we are pretty much set to go (and I do not see a major negative implication of taking it out). Less is more IMO and it will enable us to get good functionality out sooner. We will probably make some more engine enhancements during pre-beta but can freeze at any point in time.

    Andi
  • Pierre Joye at Nov 25, 2010 at 5:49 pm

    2010/11/25 Andi Gutmans <andi@zend.com>:
    -----Original Message-----
    From: Rasmus Lerdorf
    Sent: Thursday, November 25, 2010 9:27 AM
    To: Johannes Schlüter
    Cc: Andi Gutmans; Jani Taskinen; davey@php.net; PHP Internals
    Subject: Re: [PHP-DEV] Re: Hold off 5.4

    Looking through trunk I think we are in pretty good shape.  I don't think cherry-
    picking and branch merging is an issue at this point.  A
    5.4 with the performance improvements, Traits, minus the type hinting
    breakage is something we can get out pretty quickly without causing any sort of
    PHP 6 confusion or breaking existing apps.

    Btw, just to be clear I am also OK with this approach. I just wanted to make sure we consider the pros/cons of doing minor vs. major so we're all aligned re: the implications :)  I would pass on any type hinting patch because there's no consensus and if we rip it out we are pretty much set to go (and I do not see a major negative implication of taking it out). Less is more IMO and it will enable us to get good functionality out sooner. We will probably make some more engine enhancements during pre-beta but can freeze at any point in time.
    Agreed here as well. I think we can begin with the release in January
    (I mean actually begin with the 1st test release). That lets us a
    couple of weeks (don't forget December has some family mandatory
    activities for most of us :) to actually get the RFC sorted out and
    review what we have.

    By review I mean to actually focus on evaluating trunk from a
    BC/QA/design point of view. I'm not saying it is badly designed or
    whatever else negative, but that most of us were busy with the current
    active branches and other bugs.

    I'm sure these 2-3 weeks more will benefit the php-next release and
    will make us feel much more confident about it, from day 1.

    Cheers,
  • Ilia Alshanetsky at Nov 25, 2010 at 5:44 pm

    Looking through trunk I think we are in pretty good shape.  I don't
    think cherry-picking and branch merging is an issue at this point.  A
    5.4 with the performance improvements, Traits, minus the type hinting
    breakage is something we can get out pretty quickly without causing any
    sort of PHP 6 confusion or breaking existing apps.

    -Rasmus
    I Second that. The 5.4 will be backwards compatible release to the 5.3
    code as far as PHP applications are concerned. The only items that
    would be "broken" are deprecated features we may choose to remove like
    register_globals,magic_quotes_gpc,etc...

    Having this release out, to let people realize the performance
    benefits from core + apc bundling it offers would be supremely helpful
    to all users of PHP.
  • Rasmus Lerdorf at Nov 25, 2010 at 6:25 pm

    On 11/25/10 9:44 AM, Ilia Alshanetsky wrote:
    Looking through trunk I think we are in pretty good shape. I don't
    think cherry-picking and branch merging is an issue at this point. A
    5.4 with the performance improvements, Traits, minus the type hinting
    breakage is something we can get out pretty quickly without causing any
    sort of PHP 6 confusion or breaking existing apps.

    -Rasmus
    I Second that. The 5.4 will be backwards compatible release to the 5.3
    code as far as PHP applications are concerned. The only items that
    would be "broken" are deprecated features we may choose to remove like
    register_globals,magic_quotes_gpc,etc...

    Having this release out, to let people realize the performance
    benefits from core + apc bundling it offers would be supremely helpful
    to all users of PHP.
    We also need that non-null zend_parse_parameters type implemented to
    clean up the null-byte poisoning fixes in 5.3. I can't see this slowing
    us down much as it is pretty trivial. Just takes someone to sit down
    for a couple of hours and implementing it and finding all the places
    where parameters end up in paths. There are probably other places we
    don't want nulls either that currently have local checks that can be
    removed.

    -Rasmus
  • Andi Gutmans at Nov 25, 2010 at 6:33 pm

    -----Original Message-----
    From: Rasmus Lerdorf
    Sent: Thursday, November 25, 2010 10:26 AM
    To: Ilia Alshanetsky
    Cc: Johannes Schlüter; Andi Gutmans; Jani Taskinen; davey@php.net; PHP
    Internals
    Subject: Re: [PHP-DEV] Re: Hold off 5.4

    We also need that non-null zend_parse_parameters type implemented to clean
    up the null-byte poisoning fixes in 5.3. I can't see this slowing us down much as
    it is pretty trivial. Just takes someone to sit down for a couple of hours and
    implementing it and finding all the places where parameters end up in paths.
    There are probably other places we don't want nulls either that currently have
    local checks that can be removed.
    Yes I agree. We may be able to skip this check for interned strings which would be nice and potentially eliminate performance impact somewhat but it's something that would need to be looked into. It's non-trivial but doable (need to add a flag for interned strings whether they have a zero byte or not).

    Andi

Related Discussions

People

Translate

site design / logo © 2022 Grokbase