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 <[email protected]> > To: Discuss the dmd beta releases for D <[email protected]> > 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 <[email protected]> wrote: > >> On 9 December 2011 08:56, Jacob Carlborg <[email protected]> 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 > [email protected] > http://lists.puremagic.com/mailman/listinfo/dmd-beta > _______________________________________________ dmd-beta mailing list [email protected] http://lists.puremagic.com/mailman/listinfo/dmd-beta
