On Mon, Mar 5, 2012 at 12:10 PM, Don Clugston <span dir="ltr"><<a href="mailto:dac@nospam.com">dac@nospam.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On 05/03/12 19:50, Brad Anderson wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
On Mon, Mar 5, 2012 at 5:50 AM, Andrei Alexandrescu<br></div>
<<a href="mailto:SeeWebsiteForEmail@erdani.org" target="_blank">SeeWebsiteForEmail@erdani.org</a> <mailto:<a href="mailto:SeeWebsiteForEmail@erdani.org" target="_blank">SeeWebsiteForEmail@<u></u>erdani.org</a>>><div>
<div class="h5"><br>
wrote:<br>
<br>
    On 3/5/12 4:28 AM, Don Clugston wrote:<br>
<br>
        Actually this is a release process issue.<br>
        The problem is that those pages are visible at all. Nobody<br>
        should see<br>
        that, unless they pulled the docs from git.<br>
        That's not the docs for the current release, it's the docs for<br>
        the next<br>
        one. It's not just the changelog.<br>
<br>
<br>
    Agreed. We do have a process in place for phobos and druntime, but<br>
    not for the main docs.<br>
<br>
    Andrei<br>
<br>
<br></div></div><div class="im">
My opinion of how it should work is there should be a "next-release"<br>
branch where all release specific changes go.  master can be used for<br>
all changes that do not depend on the upcoming release.  Setting it up<br>
is pretty simple.<br>
<br>
     git branch next-release # branch from master<br>
     git push origin next-release # add branch to GitHub<br>
<br>
Repository contributors can just commit their release specific changes<br>
to next-release and push. We plebeians can create pull requests that<br>
target the next-release branch (how to do this isn't all that intuitive<br>
on GitHub but it's pretty trivial to actually do:<br>
<a href="http://help.github.com/send-pull-requests/" target="_blank">http://help.github.com/send-<u></u>pull-requests/</a> ).<br>
<br>
When a new version is about to be released just:<br>
<br>
     git merge next-release # while master is checked out<br>
<br>
And all release specific changes will end up on master from which you<br>
can deploy to the website.<br>
</div></blockquote>
<br>
What should the autotester do?<br>
</blockquote></div><br><div>The autotester isn't run on the website repository (at least, not to my knowledge).  If you wanted to apply this sort of setup to the other repositories I think you'd probably want it to be a bit more solid with rigidly defined branch merging conditions rather than the flowing target of 'master' on the website.  I use this model at work with great success: <a href="http://nvie.com/posts/a-successful-git-branching-model/">http://nvie.com/posts/a-successful-git-branching-model/</a></div>
<div><br></div><div>In that approach you'd just probably just run the autotester on 'develop' since 'master' almost always just represents the frozen codebase of the last release.</div><div><br></div><div>
Regards,</div><div>Brad Anderson</div>