On Sunday, October 13, 2013 23:44:27 Iain Buclaw wrote: > On Oct 13, 2013 1:08 PM, "David Nadlinger" <[email protected]> wrote: > > On Sun, Oct 13, 2013 at 12:57 AM, Jonathan M Davis <[email protected]> > > 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 _______________________________________________ dmd-internals mailing list [email protected] http://lists.puremagic.com/mailman/listinfo/dmd-internals
