[dmd-beta] Last (really, this time I mean it!) D2 beta 2.057

[Jonathan M Davis]

On Friday, December 09, 2011 09:57:52 Don Clugston wrote:
> On 9 December 2011 08:56, Jacob Carlborg <doob at me.com> wrote:
> > On 09 Dec, 2011,at 08:48 AM, Walter Bright <walter at digitalmars.com>
> > wrote:> 
> > On 12/8/2011 11:43 PM, Andrej Mitrovic wrote:
> >> Well yeah, it's the classic synchronized(WalterMutex) condition..
> > 
> > If you have a suggestion for speeding up the beta process, I'd like to
> > hear it.
> > 
> > 
> > Yes, create a public beta branch. When you think it's time to put out a
> > new release, branch out to the beta branch. Only fixes for regressions
> > (or what you/someone decides) is allowed in the beta branch. Everyone
> > else can continue to work on the main branch, nothing gets stalled.
> 
> A minor downside of that, is it would mean that releases aren't made
> from the main branch. Which might make things like bisecting a bit
> messier.
> 
> One of the challenges is that we want to run all the tests on the
> development branch, as well as on the release branch.
> OTOH if we had a dedicated release branch, that was only ever used for
> pushing release candidates, it could run a different set of tests. For
> example, it could check that all of Diemos compiles, and also a set of
> "blessed" projects, eg SciD. That would be a major step to a more
> structured release process.

Another possibility would be to branch and put the continued development on a 
branch (rather than the beta) until after the release, and then merge that 
branch into master again. Then the release is still from master. It's not as 
conceptually clean that way IMHO, but it does solve the bisecting issue. 
Having a dedicated release branch sounds better to me though.

- Jonathan M Davis