[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