On 05/03/12 20:33, Brad Anderson wrote:
On Mon, Mar 5, 2012 at 12:10 PM, Don Clugston <[email protected] <mailto:[email protected]>> wrote:On 05/03/12 19:50, Brad Anderson wrote: On Mon, Mar 5, 2012 at 5:50 AM, Andrei Alexandrescu <[email protected] <mailto:[email protected]> <mailto:SeeWebsiteForEmail@__erdani.org <mailto:[email protected]>>> wrote: On 3/5/12 4:28 AM, Don Clugston wrote: Actually this is a release process issue. The problem is that those pages are visible at all. Nobody should see that, unless they pulled the docs from git. That's not the docs for the current release, it's the docs for the next one. It's not just the changelog. Agreed. We do have a process in place for phobos and druntime, but not for the main docs. Andrei My opinion of how it should work is there should be a "next-release" branch where all release specific changes go. master can be used for all changes that do not depend on the upcoming release. Setting it up is pretty simple. git branch next-release # branch from master git push origin next-release # add branch to GitHub Repository contributors can just commit their release specific changes to next-release and push. We plebeians can create pull requests that target the next-release branch (how to do this isn't all that intuitive on GitHub but it's pretty trivial to actually do: http://help.github.com/send-__pull-requests/ <http://help.github.com/send-pull-requests/> ). When a new version is about to be released just: git merge next-release # while master is checked out And all release specific changes will end up on master from which you can deploy to the website. What should the autotester do? 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'm assuming you would. 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: http://nvie.com/posts/a-successful-git-branching-model/ 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.
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!
