On 05/03/12 20:33, Brad Anderson wrote:

On Mon, Mar 5, 2012 at 12:10 PM, Don Clugston <dac@nospam.com
<mailto: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>
<mailto: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/

<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 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.

I do, however, think the simplified version of it I proposed earlier would provide real value to the dpl.org 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.

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!