On Tue, Mar 6, 2012 at 6:34 AM, Don Clugston <[email protected]> wrote:
> On 05/03/12 20:33, Brad Anderson wrote: > >> On Mon, Mar 5, 2012 at 12:10 PM, Don Clugston <[email protected] >> <mailto:[email protected]>> wrote: >> >> On 05/03/12 19:50, Brad Anderson wrote: >> >> On Mon, Mar 5, 2012 at 5:50 AM, Andrei Alexandrescu >> <[email protected] >> <mailto:SeeWebsiteForEmail@**erdani.org<[email protected]> >> > >> <mailto:SeeWebsiteForEmail@__e**rdani.org <http://erdani.org> >> >> <mailto:SeeWebsiteForEmail@**erdani.org<[email protected]> >> >>> >> >> 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
