On Tue, Mar 6, 2012 at 6:34 AM, 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 20:33, 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 12:10 PM, Don Clugston <<a href="mailto:dac@nospam.com" target="_blank">dac@nospam.com</a><br></div><div class="im">
<mailto:<a href="mailto:dac@nospam.com" target="_blank">dac@nospam.com</a>>> wrote:<br>
<br>
On 05/03/12 19:50, Brad Anderson wrote:<br>
<br>
On Mon, Mar 5, 2012 at 5:50 AM, Andrei Alexandrescu<br>
<<a href="mailto:SeeWebsiteForEmail@erdani.org" target="_blank">SeeWebsiteForEmail@erdani.org</a><br>
<mailto:<a href="mailto:SeeWebsiteForEmail@erdani.org" target="_blank">SeeWebsiteForEmail@<u></u>erdani.org</a>><br></div>
<mailto:<a href="mailto:SeeWebsiteForEmail@" target="_blank">SeeWebsiteForEmail@</a>__<a href="http://erdani.org" target="_blank">e<u></u>rdani.org</a><div><div class="h5"><br>
<mailto:<a href="mailto:SeeWebsiteForEmail@erdani.org" target="_blank">SeeWebsiteForEmail@<u></u>erdani.org</a>>>><br>
<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<br>
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<br>
druntime, but<br>
not for the main docs.<br>
<br>
Andrei<br>
<br>
<br>
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<br>
used for<br>
all changes that do not depend on the upcoming release. Setting<br>
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<br>
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<br>
intuitive<br>
on GitHub but it's pretty trivial to actually do:<br></div></div>
<a href="http://help.github.com/send-__pull-requests/" target="_blank">http://help.github.com/send-__<u></u>pull-requests/</a><div class="im"><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<br>
which you<br>
can deploy to the website.<br>
<br>
<br>
What should the autotester do?<br>
<br>
<br></div><div class="im">
The autotester isn't run on the website repository (at least, not to my<br>
knowledge). If you wanted to apply this sort of setup to the other<br>
repositories<br>
</div></blockquote>
<br>
I'm assuming you would.<div class="im"><br></div></blockquote><div><br></div><div>I don't really contribute to dmd enough that I'd be affected by this change. It's just friendly advise that the major contributors like yourself might consider. I think it's a nice model though. That said, what you guys are currently doing seems to be working well enough.</div>
<div><br></div><div>I do, however, think the simplified version of it I proposed earlier would provide real value to the <a href="http://dpl.org">dpl.org</a> repository. I have two pending pull requests that would benefit from being able to target a 'next-release' (aka, 'develop') branch rather than the continually deployed from 'master' branch as they both rely on a merging of a dmd pull request I have pending.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
<br>
I think you'd probably want it to be a bit more solid with<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
rigidly defined branch merging conditions rather than the flowing target<br>
of 'master' on the website. I use this model at work with great<br>
success: <a href="http://nvie.com/posts/a-successful-git-branching-model/" target="_blank">http://nvie.com/posts/a-<u></u>successful-git-branching-<u></u>model/</a><br>
<br>
In that approach you'd just probably just run the autotester on<br>
'develop' since 'master' almost always just represents the frozen<br>
codebase of the last release.<br>
</blockquote>
<br></div>
The problem is 'almost always'. The case where it doesn't is just before you do a release, and it's the single most important time that you need the autotester to be running!<br>
</blockquote></div><br><div>The release branches shouldn't normally receive changes that would break testing (typically just a version bump). Usually a release- branch doesn't even leave the machine of the person rolling it. In practice I have had to make changes in release branches so it's certainly something that can happen and not having the autotester for those situations would be a loss. Maybe the autotester could be set up to run on release-* branches whenever one exists (and with higher priority).</div>
<div><br></div><div>Regards,</div><div>Brad Anderson</div>