D Stable Proposal

[1100110]

On 11/30/2012 04:40 AM, Robert wrote:
> On Fri, 2012-11-30 at 07:31 +0100, Rob T wrote:
>> One quick suggestion before I call it a day, is for there to be
>> an "experimental branch" for the great minds behind D to play
>> around with (eg UDA's etc). We probably don't want experimental
>> stuff going directly into a branch that is destined for stable.
>> Unstable should be for items that are relatively finalized in
>> terms of design and agreement that the concept is to be
>> eventually incorporated into stable, i.e., moving a new feature
>> into unstable starts the refinement process towards a stable
>> release of that feature.
>
> Totally agreed. In the development branch only already finalized things
> should be merged.
>
> Having official experimental branch(es) is a good idea.  I think the
> things people are working on should be easily accessible. So other
> people can contribute and test the stuff. These branches should then
> also be included in dpaste.dzfl.pl. Maybe a dmd-experimental project,
> where people can get access to, very easily. So they can push their
> branches there. It should be as easy for people to try out experimental
> things as to try out things from the development branch, to get as much
> early testing as possible. Automatic creation of binary releases would
> also be cool.
>
> So the workflow could be something like:
>
> 1. Document on a dedicated wiki page that you start working on feature X
> or bug fix Y.
> 2. Get started on a private/semipublic feature branch.
> 3. As soon as you got something push it to dmd-experimental
> 4. Continue to work and improve things there
> 5. Experimental branches are considered for inclusion in devel.
I think you would end up targeting experimental to prevent clashes with 
other stuff that has also yet to be merged.  From what I see, whatever 
you call it, upstream should remain upstream.  Maybe its a good Idea, 
but I would consider that out of our hands.

A Testing branch that new features are pulled to after inclusion in 
upstream would be nice, and allow Testing to handle it's own releases 
and have it's own guarantees.  That would enable the short term releases 
and early testing.  But I do not want to interfere with devel.

> 6. Things are tested in an integrated way in devel, with binary releases
> every two months or so. (Much like we have now)
> 7. At predefined intervals you branch of a release branch and stabilize
> things further.
> 8. Release branch is merged in dmd-stable/master
>
>
> Someone posted this, as why not to use feature branches:
>
> http://www.youtube.com/watch?v=xzstASOvqNc&feature=youtu.be
Fixin to sleep, I'll watch it in the morning and respond.
>
> I personally don't think that feature branches are the problem, but more
> a lack of communication. If people work on the same stuff you get merge
> conflicts, that is granted, so you should know on what people are
> working before starting to work. A wiki page where you add a link to
> your feature branch and what you are currently working on and
> dmd-experimental could help in this regard.
>
This is a a question for Walter et al to answer.

I don't think we should define their workflow, In fact I'd prefer that 
the devel remain completely under Walter's domain.  Testing branch could 
be useful, though.