On Mon, Mar 5, 2012 at 12:10 PM, Don Clugston <dac@nospam.com> wrote:
On 05/03/12 19:50, Brad Anderson wrote:
On Mon, Mar 5, 2012 at 5:50 AM, Andrei Alexandrescu<SeeWebsiteForEmail@erdani.org <mailto:SeeWebsiteForEmail@erdani.org>>
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/ ).
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?