Thread overview | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|
|
March 27, 2015 change in github workflow! | ||||
---|---|---|---|---|
| ||||
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 |
March 27, 2015 Re: change in github workflow! | ||||
---|---|---|---|---|
| ||||
Posted in reply to Martin Nowak | 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
|
March 27, 2015 Re: change in github workflow! | ||||
---|---|---|---|---|
| ||||
Posted in reply to H. S. Teoh | 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 |
March 27, 2015 Re: change in github workflow! | ||||
---|---|---|---|---|
| ||||
Posted in reply to Martin Nowak | 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).
|
March 27, 2015 Re: change in github workflow! | ||||
---|---|---|---|---|
| ||||
Posted in reply to Martin Nowak | 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.
|
March 27, 2015 Re: change in github workflow! | ||||
---|---|---|---|---|
| ||||
Posted in reply to Brad Anderson | 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.
|
March 28, 2015 Re: change in github workflow! | ||||
---|---|---|---|---|
| ||||
Posted in reply to Martin Nowak | 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.
|
March 28, 2015 Re: change in github workflow! | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | 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 |
Copyright © 1999-2021 by the D Language Foundation