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

Steve Schveighoffer schveiguy at yahoo.com
Fri Dec 9 06:47:18 PST 2011


This *has* to be a solved problem with git, some google research is in order.  I'm thinking there should be some way to construct a branch that places the beta fixes before the development changes.  I know with something like svn, branches should be discarded once you merge them back to their source, but is git the same way?

I agree we should find a better way to avoid gumming up the development cycle with a beta cycle.


-Steve



----- Original Message -----
> From: Jason House <jason.james.house at gmail.com>
> To: Discuss the dmd beta releases for D <dmd-beta at puremagic.com>
> Cc: 
> Sent: Friday, December 9, 2011 9:36 AM
> Subject: Re: [dmd-beta] Last (really, this time I mean it!) D2 beta 2.057
> 
> On Dec 9, 2011, at 3:57 AM, Don Clugston <dclugston at googlemail.com> wrote:
> 
>>  On 9 December 2011 08:56, Jacob Carlborg <doob at me.com> wrote:
>>> 
>>> 
>>> 
>>>  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.
> 
> It really should not be that bad. It is good practice to apply patches in the 
> release branch to the main branch as well. Even if that is not done for the 
> "one fix per day", one merge after a release will at least allow you 
> to discover it was one of the release candidate patches and you can do a second 
> bisect if required.
> _______________________________________________
> dmd-beta mailing list
> dmd-beta at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-beta
> 


More information about the dmd-beta mailing list