[dmd-internals] Preparing for beta

Jonathan M Davis jmdavisProg at gmx.com
Sun Oct 13 16:01:35 PDT 2013


On Sunday, October 13, 2013 23:44:27 Iain Buclaw wrote:
> On Oct 13, 2013 1:08 PM, "David Nadlinger" <code at klickverbot.at> wrote:
> > On Sun, Oct 13, 2013 at 12:57 AM, Jonathan M Davis <jmdavisProg at gmx.com>
> 
> wrote:
> > > […] and merges could continue to happen as normal on the master
> > > branch with the fixes that actually need to get into the release then
> 
> being
> 
> > > merge separately into the release branch.
> > 
> > Another model is that pull requests that should go into the release
> > are made against the release branch, where they can be merged back to
> > master, avoiding cherry-picking (and thus duplicating) commits.
> 
> Or perhaps simply not merging new features / enhancements until the next
> release (requires self moderation).

Yes, but this pretty much defeats the purpose of branching during the beta 
process instead of just before the release. That's what we did before, and 
there were complaints about that, because it effectively puts normal 
development at a standstill until the release actually occurs, and the beta 
process isn't always short. Branching for the beta allows us to continue to 
merge pull requests as normal without affecting the beta. Perhaps pull requests 
that should end up in the beta should target the release branch instead of 
master and get merged back into master rather than the other way around, but 
either way, it becomes possible to continue normal development during the beta 
rather than blocking everything but the regressions until the release.

- Jonathan m Davis


More information about the dmd-internals mailing list