<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Jan 23, 2014 at 12:01 PM, Walter Bright <span dir="ltr"><<a href="mailto:walter@digitalmars.com" target="_blank">walter@digitalmars.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

<div class="im">
<br></div>
I agree, I don't know what's wrong with what we had before:<br>
<br>
1. All pull requests get merged to master<br>
2. Create 2.065 branch<br>
3. Cherry-pick from master to 2.065 as required<br>
4. Tag 2.065.whatever as releases get done on that branch<br>
<br>
Easy, simple. All these other procedures seem like massive over-engineering to me.<div class=""><div class="h5"><br></div></div></blockquote><div><br></div><div>I actually wrote up the simplified proposal to switch the formal process over to almost exactly what you just said (with the non essential difference that release branches are temporary and don't have a version in their name). What we had before[1] specifically forbade cherry-picking and instead relied on all contributors targeting multiple branches with their pull requests (which almost nobody ever did as Andrew pointed out).</div>

<div><br></div><div>If we want to use release branches that stick around forever that's fine. Steps 1 and 3 are all I care about having in any release process.</div><div><br></div><div>[1] <a href="http://wiki.dlang.org/Development_and_Release_Process">http://wiki.dlang.org/Development_and_Release_Process</a></div>

</div></div></div>