[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