We replace the old cherry-pick approach by introducing stable branches, more info here http://wiki.dlang.org/DIP75#Branching_strategy.

This avoids having to manually identify bugfixes to be cherry-picked
into the release branch (2.067.0 is missing at least 2 fixes) and helps
us to do point releases.
Also merging instead of copying commits allows to reliably identify
which releases contain a certain fix.

From now on, any pull request to fix a regression or an important bug
should target the stable branch instead of master. Changes on stable
should be as low-risk as possible, be backward compatible, and avoid
adding deprecations.
Unfortunately github doesn't allow to retarget pull requests, so if a
pull targets the wrong branch, it needs to be reopened.

We'll soon reconfigure the auto-tester to test stable as well.

-Martin

On Fri, Mar 27, 2015 at 07:21:10PM +0100, Martin Nowak via Digitalmars-d wrote:
> We replace the old cherry-pick approach by introducing stable branches, more info here http://wiki.dlang.org/DIP75#Branching_strategy.

+1. It's about time! Thanks for making it finally happen!!


--T

On 3/27/15 11:28 AM, H. S. Teoh via Digitalmars-d wrote:
> On Fri, Mar 27, 2015 at 07:21:10PM +0100, Martin Nowak via Digitalmars-d wrote:
>> We replace the old cherry-pick approach by introducing stable branches,
>> more info here http://wiki.dlang.org/DIP75#Branching_strategy.
>
> +1. It's about time! Thanks for making it finally happen!!

Indeed! Thanks David and Martin. I marked the status of http://wiki.dlang.org/DIP75 as "Approved experimentally for 2.068". -- Andrei

On Friday, 27 March 2015 at 18:21:32 UTC, Martin Nowak wrote:
> We replace the old cherry-pick approach by introducing stable branches,
> more info here http://wiki.dlang.org/DIP75#Branching_strategy.
>
> [snip]

Sounds good. It's not clear who will be merging stable into master and when (it's a shame Github doesn't let you target multiple branches).

Good to hear!

> Unfortunately github doesn't allow to retarget pull requests, so if a
pull targets the wrong branch, it needs to be reopened.

The targeted branch is only important for three reasons:

1. Documents the intent of the pull request (the specific point release being targeted)
2. Allows the use of auto merge
3. It avoid unrelated code change conflicts, as in added features/bug fixes that were not there in the desired point release.

The third is the only real reason that a pull request should need to be reopened. Otherwise a incorrectly targeted pull should be fairly easy to apply. But rejecting incorrectly placed pull requests can help to remind developers where to develop their request against.

On Friday, 27 March 2015 at 21:37:23 UTC, Brad Anderson wrote:
> It's not clear who will be merging stable into master and when (it's a shame Github doesn't let you target multiple branches).

Not sure we need a strict rule here and it shouldn't be necessary to do this after each merge. Could be automated, I.e. once a day a pull request from stable to master is opened.
That leaves open who will deal with merge conflicts, but I'm sure some useful convention will emerge.

On 28/03/2015 7:21 a.m., Martin Nowak wrote:
> We replace the old cherry-pick approach by introducing stable branches,
> more info here http://wiki.dlang.org/DIP75#Branching_strategy.
>
> This avoids having to manually identify bugfixes to be cherry-picked
> into the release branch (2.067.0 is missing at least 2 fixes) and helps
> us to do point releases.
> Also merging instead of copying commits allows to reliably identify
> which releases contain a certain fix.
>
>  From now on, any pull request to fix a regression or an important bug
> should target the stable branch instead of master. Changes on stable
> should be as low-risk as possible, be backward compatible, and avoid
> adding deprecations.
> Unfortunately github doesn't allow to retarget pull requests, so if a
> pull targets the wrong branch, it needs to be reopened.
>
> We'll soon reconfigure the auto-tester to test stable as well.
>
> -Martin

Don't forget to add this to CONTRIBUTIONS.md file! That way Github can yell at you to read it + remember about this.

On 03/27/2015 05:25 PM, Andrei Alexandrescu wrote:
> On 3/27/15 11:28 AM, H. S. Teoh via Digitalmars-d wrote:
>> On Fri, Mar 27, 2015 at 07:21:10PM +0100, Martin Nowak via Digitalmars-d wrote:
>>> We replace the old cherry-pick approach by introducing stable branches, more info here http://wiki.dlang.org/DIP75#Branching_strategy.
>>
>> +1. It's about time! Thanks for making it finally happen!!
> 
> Indeed! Thanks David and Martin. I marked the status of http://wiki.dlang.org/DIP75 as "Approved experimentally for 2.068". -- Andrei
> 

Could we please try to keep http://wiki.dlang.org/DIPs up to date?  I just added DIPs 74 & 75 and have found it useful in the past to find the status of a DIP whose number I don't remember.  Alternately, we can delete the page if it's not going to be maintained.

-- 
Paul O'Neil
Github / IRC: todayman