D Changelog is messed up.

[Don Clugston]

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