On Mon, Mar 5, 2012 at 12:10 PM, Don Clugston <[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:SeeWebsiteForEmail@**erdani.org<[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 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. Regards, Brad Anderson
