I'd like to hold off on merging pull requests until we get the beta released (but keep on generating pull requests!), unless those PR's resolve 'regression' issues, or 'critical' or 'blocker' issues with non-disruptive changes.

Current list:

http://d.puremagic.com/issues/buglist.cgi?query_format=advanced&bug_severity=regression&bug_severity=blocker&bug_severity=critical&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&version=D1%20%26%20D2&version=D2
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

On 10 October 2013 23:56, Walter Bright <walter@digitalmars.com> wrote:
> I'd like to hold off on merging pull requests until we get the beta released (but keep on generating pull requests!), unless those PR's resolve 'regression' issues, or 'critical' or 'blocker' issues with non-disruptive changes.
>
> Current list:
>
> http://d.puremagic.com/issues/buglist.cgi?query_format=advanced&bug_severity=regression&bug_severity=blocker&bug_severity=critical&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&version=D1%20%26%20D2&version=D2
> _______________________________________________
> dmd-internals mailing list
> dmd-internals@puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-internals


It's about time!  :o)

-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

On Fri, Oct 11, 2013 at 12:56 AM, Walter Bright <walter@digitalmars.com> wrote:
> I'd like to hold off on merging pull requests until we get the beta released (but keep on generating pull requests!), unless those PR's resolve 'regression' issues, or 'critical' or 'blocker' issues with non-disruptive changes.

So we are giving up on the idea of a release branch?

David
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

On 10/12/2013 9:52 AM, David Nadlinger wrote:
> On Fri, Oct 11, 2013 at 12:56 AM, Walter Bright <walter@digitalmars.com> wrote:
>> I'd like to hold off on merging pull requests until we get the beta released
>> (but keep on generating pull requests!), unless those PR's resolve
>> 'regression' issues, or 'critical' or 'blocker' issues with non-disruptive
>> changes.
> So we are giving up on the idea of a release branch?
>

Not at all. I'll set one up soon.
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

On Saturday, October 12, 2013 11:09:19 Walter Bright wrote:
> On 10/12/2013 9:52 AM, David Nadlinger wrote:
> > On Fri, Oct 11, 2013 at 12:56 AM, Walter Bright <walter@digitalmars.com>
wrote:
> >> I'd like to hold off on merging pull requests until we get the beta released (but keep on generating pull requests!), unless those PR's resolve 'regression' issues, or 'critical' or 'blocker' issues with non-disruptive changes.
> > 
> > So we are giving up on the idea of a release branch?
> 
> Not at all. I'll set one up soon.

It's just that normally the thing would be to create the release branch and never tell anyone to stop merging pull request. You'd just create the branch for the release, 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.

- Jonathan M Davis
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

On Sun, Oct 13, 2013 at 12:57 AM, Jonathan M Davis <jmdavisProg@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.

David
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

On Oct 13, 2013 1:08 PM, "David Nadlinger" <code@klickverbot.at> wrote:
>
> On Sun, Oct 13, 2013 at 12:57 AM, Jonathan M Davis <jmdavisProg@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).

Regards
-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

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