FAQ
Hi,

I was wondering how we are supposed to handle NEWS entries when a fix
goes into both branches, PHP-5.4 and 5.5. IIRC we used to add the BFN
only to the lowest numbered branch, but then again that was at times
we had mostly onle one stable release branch...

--
Regards,
Mike

Search Discussions

  • Adam Harvey at Oct 8, 2013 at 5:16 pm

    On 8 October 2013 06:46, Michael Wallner wrote:
    I was wondering how we are supposed to handle NEWS entries when a fix
    goes into both branches, PHP-5.4 and 5.5. IIRC we used to add the BFN
    only to the lowest numbered branch, but then again that was at times
    we had mostly onle one stable release branch...
    The way I've done it (and it seems like most developers are doing it
    now) is to add the same entry to each stable branch as I merge
    upwards, so the 5.4 and 5.5 NEWS files each end up with something
    like:

    - Extension:
       . Fixed bug #12345 (luggage combination is weak). (Adam)

    I think the bug number really has to be in each branch for the NEWS
    file to be useful — users need to be able to find out at a glance
    what's been fixed from 5.5.4 to 5.5.5, for instance.

    Adam
  • Pierre Joye at Oct 9, 2013 at 2:32 am

    On Tue, Oct 8, 2013 at 7:09 PM, Adam Harvey wrote:
    On 8 October 2013 06:46, Michael Wallner wrote:
    I was wondering how we are supposed to handle NEWS entries when a fix
    goes into both branches, PHP-5.4 and 5.5. IIRC we used to add the BFN
    only to the lowest numbered branch, but then again that was at times
    we had mostly onle one stable release branch...
    The way I've done it (and it seems like most developers are doing it
    now) is to add the same entry to each stable branch as I merge
    upwards, so the 5.4 and 5.5 NEWS files each end up with something
    like:

    - Extension:
    . Fixed bug #12345 (luggage combination is weak). (Adam)

    I think the bug number really has to be in each branch for the NEWS
    file to be useful — users need to be able to find out at a glance
    what's been fixed from 5.5.4 to 5.5.5, for instance.
    agreed.

    I never really liked the "lowest branch" only way, too confusing and
    hard to see what was fixed where.

    Cheers,
    --
    Pierre

    @pierrejoye | http://www.libgd.org
  • Martin Keckeis at Oct 9, 2013 at 6:01 am
    Hello togehter,

    2013/10/9 Pierre Joye <pierre.php@gmail.com>
    On Tue, Oct 8, 2013 at 7:09 PM, Adam Harvey wrote:
    On 8 October 2013 06:46, Michael Wallner wrote:
    I was wondering how we are supposed to handle NEWS entries when a fix
    goes into both branches, PHP-5.4 and 5.5. IIRC we used to add the BFN
    only to the lowest numbered branch, but then again that was at times
    we had mostly onle one stable release branch...
    The way I've done it (and it seems like most developers are doing it
    now) is to add the same entry to each stable branch as I merge
    upwards, so the 5.4 and 5.5 NEWS files each end up with something
    like:

    - Extension:
    . Fixed bug #12345 (luggage combination is weak). (Adam)

    I think the bug number really has to be in each branch for the NEWS
    file to be useful — users need to be able to find out at a glance
    what's been fixed from 5.5.4 to 5.5.5, for instance.
    agreed.

    I never really liked the "lowest branch" only way, too confusing and
    hard to see what was fixed where.

    Cheers,
    --
    Pierre

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

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
    As more or less a "enduser" i have to agree. Writing in both is the easiest
    way, to get a "quick" overview what is releavant.
  • Michael Wallner at Oct 9, 2013 at 6:18 am

    On 9 October 2013 08:01, Martin Keckeis wrote:
    Hello togehter,

    2013/10/9 Pierre Joye <pierre.php@gmail.com>
    On Tue, Oct 8, 2013 at 7:09 PM, Adam Harvey wrote:
    On 8 October 2013 06:46, Michael Wallner wrote:
    I was wondering how we are supposed to handle NEWS entries when a fix
    goes into both branches, PHP-5.4 and 5.5. IIRC we used to add the BFN
    only to the lowest numbered branch, but then again that was at times
    we had mostly onle one stable release branch...
    The way I've done it (and it seems like most developers are doing it
    now) is to add the same entry to each stable branch as I merge
    upwards, so the 5.4 and 5.5 NEWS files each end up with something
    like:

    - Extension:
    . Fixed bug #12345 (luggage combination is weak). (Adam)

    I think the bug number really has to be in each branch for the NEWS
    file to be useful — users need to be able to find out at a glance
    what's been fixed from 5.5.4 to 5.5.5, for instance.
    agreed.

    I never really liked the "lowest branch" only way, too confusing and
    hard to see what was fixed where.

    Cheers,
    --
    Pierre

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

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
    As more or less a "enduser" i have to agree. Writing in both is the easiest
    way, to get a "quick" overview what is releavant.
    Thanks for your feedback! I fixed NEWS for the upcoming releases.
    Please let us have an eye on it in the future!

    --
    Regards,
    Mike
  • Michael Wallner at Oct 9, 2013 at 7:07 am

    Thanks for your feedback! I fixed NEWS for the upcoming releases.
    Please let us have an eye on it in the future!
    Okay -- looking at NEWS.GIT-RULES it actually says the opposite:

    2. All news updates intended for public viewing, such as new features,
           bug fixes, improvements, etc., should go into the NEWS file of the
           *first* to be released version with the given change. In other words
           any NEWS file change only needs to done in one branch.

    How about changing it to:

    2. All news updates intended for public viewing, such as new features,
           bug fixes, improvements, etc., should go into the NEWS file of *any
           stable release* version with the given change. In other words,
           news about a bug fix which went into PHP-5.4, PHP-5.5 and master
           should be noted in both PHP-5.4/NEWS and PHP-5.5/NEWS but
           not master, which is not a public released version yet.

    PS: I post that for other people that had not time to notice this
    discussion and I will most probably give a week or so for others to
    speek up before changing any settled rules. Could well be there are
    people who do not want to write two NEWS entries :)

    --
    Regards,
    Mike
  • Adam Harvey at Oct 9, 2013 at 7:17 am

    On 9 October 2013 00:07, Michael Wallner wrote:
    Okay -- looking at NEWS.GIT-RULES it actually says the opposite:

    2. All news updates intended for public viewing, such as new features,
    bug fixes, improvements, etc., should go into the NEWS file of the
    *first* to be released version with the given change. In other words
    any NEWS file change only needs to done in one branch.

    How about changing it to:

    2. All news updates intended for public viewing, such as new features,
    bug fixes, improvements, etc., should go into the NEWS file of *any
    stable release* version with the given change. In other words,
    news about a bug fix which went into PHP-5.4, PHP-5.5 and master
    should be noted in both PHP-5.4/NEWS and PHP-5.5/NEWS but
    not master, which is not a public released version yet.
    +1. Copying the NEWS entry across is pretty easy when merging upwards,
    even if you're using the touch driver for NEWS.

    Adam
  • Pierre Joye at Oct 9, 2013 at 7:37 am

    On Wed, Oct 9, 2013 at 9:07 AM, Michael Wallner wrote:
    Thanks for your feedback! I fixed NEWS for the upcoming releases.
    Please let us have an eye on it in the future!
    Okay -- looking at NEWS.GIT-RULES it actually says the opposite:

    2. All news updates intended for public viewing, such as new features,
    bug fixes, improvements, etc., should go into the NEWS file of the
    *first* to be released version with the given change. In other words
    any NEWS file change only needs to done in one branch.

    How about changing it to:

    2. All news updates intended for public viewing, such as new features,
    bug fixes, improvements, etc., should go into the NEWS file of *any
    stable release* version with the given change. In other words,
    news about a bug fix which went into PHP-5.4, PHP-5.5 and master
    should be noted in both PHP-5.4/NEWS and PHP-5.5/NEWS but
    not master, which is not a public released version yet.

    PS: I post that for other people that had not time to notice this
    discussion and I will most probably give a week or so for others to
    speek up before changing any settled rules. Could well be there are
    people who do not want to write two NEWS entries :)
    +1

    And maybe we should begin to consider to force the new commit message
    format? (see https://wiki.php.net/vcs/gitworkflow#new_commit_message_format),
    may need a RFC and be done, almost :)


    --
    Pierre

    @pierrejoye | http://www.libgd.org
  • Christopher Jones at Oct 9, 2013 at 4:57 pm

    On 10/09/2013 12:07 AM, Michael Wallner wrote:
    Thanks for your feedback! I fixed NEWS for the upcoming releases.
    Please let us have an eye on it in the future!
    Okay -- looking at NEWS.GIT-RULES it actually says the opposite:

    2. All news updates intended for public viewing, such as new features,
    bug fixes, improvements, etc., should go into the NEWS file of the
    *first* to be released version with the given change. In other words
    any NEWS file change only needs to done in one branch.

    How about changing it to:

    2. All news updates intended for public viewing, such as new features,
    bug fixes, improvements, etc., should go into the NEWS file of *any
    stable release* version with the given change. In other words,
    news about a bug fix which went into PHP-5.4, PHP-5.5 and master
    should be noted in both PHP-5.4/NEWS and PHP-5.5/NEWS but
    not master, which is not a public released version yet.

    PS: I post that for other people that had not time to notice this
    discussion and I will most probably give a week or so for others to
    speek up before changing any settled rules. Could well be there are
    people who do not want to write two NEWS entries :)
    +1.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupphp-internals @
categoriesphp
postedOct 8, '13 at 1:46p
activeOct 9, '13 at 4:57p
posts9
users5
websitephp.net

People

Translate

site design / logo © 2022 Grokbase