On Mon, Mar 5, 2012 at 5:50 AM, Andrei Alexandrescu <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.

I've actually got a pull request <https://github.com/D-Programming-Language/d-programming-language.org/pull/95> that is exactly the right fit for this type of setup.  Pulling it in to master means users would expect it to work but it won't until after the next dmd release (which would hopefully include the companion pull request making the change). As it stands now I just have to be sure to make the pull conditions clear in the description which, frankly, doesn't seem to work all that well (e.g., see the recent windows curl pulls that were merged prematurely).

Regards,
Brad Anderson