D Changelog is messed up.

[Brad Anderson]

On Mon, Mar 5, 2012 at 12:10 PM, Don Clugston <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@**erdani.org<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 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20120305/2638c0b1/attachment.html>