digitalmars.D - change in github workflow!
- Martin Nowak (15/15) Mar 27 2015 We replace the old cherry-pick approach by introducing stable branches,
- H. S. Teoh via Digitalmars-d (3/5) Mar 27 2015 +1. It's about time! Thanks for making it finally happen!!
- Andrei Alexandrescu (4/8) Mar 27 2015 Indeed! Thanks David and Martin. I marked the status of
- Paul O'Neil (8/20) Mar 27 2015 Could we please try to keep http://wiki.dlang.org/DIPs up to date? I
- Brad Anderson (4/8) Mar 27 2015 Sounds good. It's not clear who will be merging stable into
- Martin Nowak (6/8) Mar 27 2015 Not sure we need a strict rule here and it shouldn't be necessary
- Jesse Phillips (14/16) Mar 27 2015 pull targets the wrong branch, it needs to be reopened.
- Rikki Cattermole (3/18) Mar 27 2015 Don't forget to add this to CONTRIBUTIONS.md file! That way Github can
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
Mar 27 2015
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
Mar 27 2015
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:Indeed! Thanks David and Martin. I marked the status of http://wiki.dlang.org/DIP75 as "Approved experimentally for 2.068". -- AndreiWe 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!!
Mar 27 2015
Paul O'Neil <redballoon36 gmail.com> On 03/27/2015 05:25 PM, Andrei Alexandrescu wrote:On 3/27/15 11:28 AM, H. S. Teoh via Digitalmars-d wrote: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: todaymanOn Fri, Mar 27, 2015 at 07:21:10PM +0100, Martin Nowak via Digitalmars-d wrote:Indeed! Thanks David and Martin. I marked the status of http://wiki.dlang.org/DIP75 as "Approved experimentally for 2.068". -- AndreiWe 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!!
Mar 27 2015
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).
Mar 27 2015
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.
Mar 27 2015
Good to hear!Unfortunately github doesn't allow to retarget pull requests, so if apull 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.
Mar 27 2015
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. -MartinDon't forget to add this to CONTRIBUTIONS.md file! That way Github can yell at you to read it + remember about this.
Mar 27 2015