<div dir="ltr">I emailed you directly earlier but I'd like to point it out here that I think the release process is far, far too complicated. The people who designed it obviously worked hard on it and it there is definitely value in what they designed but in practice there are clearly a lot of problems following it (as this email chain shows). One problem is that with the current approach it's impossible to do a bugfix only release without freezing all feature development (i.e. cherry-picking is forbidden but all commits must still go to master) which is unacceptable and was the original reason why a Release Process was created.<div>

<br></div><div>I put together a very simplified approach that results in only a single person, the Release Manager, have to learn it and do any work and only during a small feature freeze/beta window. Everyone else just makes pull requests to master. Things can be merged regardless of whether a release is in progress or not.</div>

<div><br></div><div><a href="http://wiki.dlang.org/Simplified_Release_Process_Proposal">http://wiki.dlang.org/Simplified_Release_Process_Proposal</a><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">

On Fri, Jan 10, 2014 at 1:50 PM, Andrew Edwards <span dir="ltr"><<a href="mailto:edwards.ac@gmail.com" target="_blank">edwards.ac@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="HOEnZb"><div class="h5">On 1/9/14, 7:24 PM, Walter Bright wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Rather than trying to fix the 2.065 branch, perhaps we should simply abandon it and go with 2.066?<br>
<br>
______________________________<u></u>_________________<br>
dmd-beta mailing list<br>
<a href="mailto:dmd-beta@puremagic.com" target="_blank">dmd-beta@puremagic.com</a><br>
<a href="http://lists.puremagic.com/mailman/listinfo/dmd-beta" target="_blank">http://lists.puremagic.com/<u></u>mailman/listinfo/dmd-beta</a><br>
</blockquote></div></div>
I'm not against that. There are a couple of commits that I think were injected directly into the 2.065 branch that may need to be merged into master but other than that I don't see any issues. As Martin alluded to though, it is necessary to provide more attention to the fixes--specifically regressions--necessary to the getting the release out the door. No doubt they would be simpler to identify if they were air-marked for that branch instead of master, but that requires everyone to embrace the methodology outlined in [1].<br>


<br>
Once the branch is prepared:<br>
    a. implementation of new features should cease<br>
    b. pull request for fixes should be made against and merged with the branch<br>
    c. merger of pulls made against master should be suspended<br>
    d. attention given to outstanding regressions<br>
    e. upon resolution of final regression, the tag is created and the beta built and released<br>
<br>
This would make for a much smoother release process than what we have going on right now. It's unacceptable to wait 20+ days for to merge pulls air-marked for the current release cycle, which is what's happening.<br>


<br>
1) <a href="http://wiki.dlang.org/Development_and_Release_Process" target="_blank">http://wiki.dlang.org/<u></u>Development_and_Release_<u></u>Process</a><div class="HOEnZb"><div class="h5"><br>
______________________________<u></u>_________________<br>
dmd-beta mailing list<br>
<a href="mailto:dmd-beta@puremagic.com" target="_blank">dmd-beta@puremagic.com</a><br>
<a href="http://lists.puremagic.com/mailman/listinfo/dmd-beta" target="_blank">http://lists.puremagic.com/<u></u>mailman/listinfo/dmd-beta</a><br>
</div></div></blockquote></div><br></div>