D Changelog is messed up.

[Brad Anderson]

On Tue, Mar 6, 2012 at 6:34 AM, Don Clugston <dac at nospam.com> wrote:

> 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@**erdani.org<SeeWebsiteForEmail at erdani.org>
>> >
>>        <mailto:SeeWebsiteForEmail at __e**rdani.org <http://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/>
>>
>>        <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/<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!
>

The release branches shouldn't normally receive changes that would break
testing (typically just a version bump).  Usually a release- branch doesn't
even leave the machine of the person rolling it.  In practice I have had to
make changes in release branches so it's certainly something that can
happen and not having the autotester for those situations would be a loss.
Maybe the autotester could be set up to run on release-* branches whenever
one exists (and with higher priority).

Regards,
Brad Anderson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20120306/77c13b3e/attachment.html>