D versionning

[Masahiro Nakagawa]

On Monday, 16 July 2012 at 01:38:38 UTC, Alex Rønne Petersen 
wrote:
> On 16-07-2012 03:11, Andrei Alexandrescu wrote:
>> On 7/15/12 7:44 PM, Adam Wilson wrote:
>>> I should note that we use this exact model for every project 
>>> we have
>>> where I work and that it is been highly successful at keeping 
>>> those five
>>> points of tension moderated. And our users can actually get 
>>> work done
>>> without waiting for weeks and months because thing X is just 
>>> plain
>>> broken, which in turn makes us look good. (Improving Loyalty)
>>
>> Allow me to propose something.
>>
>> Right now all dmd changes get merged in the head. Suppose we 
>> find a
>> volunteer in the community who is:
>>
>> 1. Highly motivated
>>
>> 2. With a good understanding of D
>>
>> 3. Expert with git
>>
>> 4. Reliable
>>
>> I wonder if it's possible that that person cherry-picks 
>> commits from
>> HEAD into two separate branches: bugfixes and unstable. It 
>> should be
>> easy to create installers etc. for those.
>>
>> If we see this works well and gathers steady interest, we can 
>> improve it
>> and make it the practice of the entire team.
>>
>> Would this be possible?
>>
>>
>> Andrei
>>
>
> I propose a slight variation:
>
> * master: This is the 'incoming' branch. Unstable, in-dev, etc. 
> It's easier this way since pull requests will usually target 
> this branch and build bots will test this.
> * stable: This branch contains only bug fixes to existing 
> language features, and enhancements that do not in any way 
> impact existing features (or break code). Should be manually 
> maintained based on master.
>
> That's it. I don't see a need for any added complexity to this 
> simple model. Feel free to destroy as you see fit, though!

git-flow is the other candidate.

https://github.com/nvie/gitflow/

See more detail:

http://nvie.com/posts/a-successful-git-branching-model/