Am 09.12.2011, 15:47 Uhr, schrieb Steve Schveighoffer <schveiguy at yahoo.com>:

> 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?

Nope, cause git has real branches.
svn "branches" and "tags" are just special words for dumb copies.

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

On 12/9/2011 6:33 AM, Jacob Carlborg wrote:
>
>
> Then what's the rush in getting the release out even if there are known regressions?
>
>

At some point, it is necessary to ship. It imposes a reality check on the vast amount of changes.

On 12/9/2011 6:21 AM, Steve Schveighoffer wrote:
> One question, is it good to file quick-fix bugs for historical purposes?  I mean I just discovered the bug, it's not in a released version yet, and it may be fixed or nullified momentarily.

No, I think that's pointless. It'd be like filing bug reports for transitory syntax errors.

Might not be good to add into bugzilla, but they could make good items for a test suite.

Sent from my iPhone

On Dec 9, 2011, at 4:43 PM, Walter Bright <walter at digitalmars.com> wrote:

> 
> 
> On 12/9/2011 6:21 AM, Steve Schveighoffer wrote:
>> One question, is it good to file quick-fix bugs for historical purposes?  I mean I just discovered the bug, it's not in a released version yet, and it may be fixed or nullified momentarily.
> 
> No, I think that's pointless. It'd be like filing bug reports for transitory syntax errors.
> _______________________________________________
> dmd-beta mailing list
> dmd-beta at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-beta