Breaking D2 language/spec changes with D1 being discontinued in a month

[foobar]

On Thursday, 29 November 2012 at 09:37:57 UTC, Manu wrote:
> On 29 November 2012 03:48, deadalnix <deadalnix at gmail.com> 
> wrote:
>
>> On Thursday, 29 November 2012 at 01:29:12 UTC, Jonathan M 
>> Davis wrote:
>>
>>> Since master will almost certainly be the development branch, 
>>> I don't see
>>> how
>>>
>>> that's a problem. The stable branch will be a separate 
>>> branch, and
>>> whoever is
>>> managing the stable branch will merge stuff from the master 
>>> branch into
>>> it.
>>>
>>>
>> In this case, all bug fixes are mixed with new feature and 
>> then have to be
>> separated afterward and remerged into the stable branch. This 
>> is useless
>> work and it is likely to cause merge conflict in the stable 
>> branch.
>>
>> Additionnaly, this become to really suck when several new 
>> features are dev
>> at the same time.
>>
>> Finally, yhis is completely inconsistent with how github work 
>> in the first
>> place.
>>
>> master make sense as an unstable branch, a release candidate, 
>> a beta or
>> whatever, but certainly not a dev branch.
>
>
> Why don't you document precisely what branches you think should 
> exist, and
> the working merge/rebase policies.
> I'm actually very curious to know.
>
>
>  Granted, major stuff like 64-bit Windows support and UDAs 
> should probably
>>> be
>>> introduced on branches separate from master, and it's still a 
>>> problem if
>>> they're not, but it won't affect the stable branch if they're 
>>> not.
>>>
>>>
>> It will become all bigfixes will be based on code that 
>> contains the new
>> feature.

Manu:
This was mentioned in the group numerous times before, here's one 
more time to increase awareness even more:
git flow - http://nvie.com/posts/a-successful-git-branching-model/
should be easily adapted for the D development process.

Walter:
a champion cannot solve this issue as this requires participation 
of all (core) developers. Otherwise we get a _lot_ of redundant 
after the fact maintenance work. The only way to succeed long 
term is to remove all single points of failures - the single 
master branch on the technical side, and a single decision making 
person (you) on the management side. It can only be possible if 
you agree to relinquish some control and allow other core 
developers to _fully_ participate. that includes - review/pull 
powers, managing their own branches, taking part in the decision 
making process as to what feature is mature enough to be 
"released" on the stable branch. No champion can do any of that 
as it requires your agreement and participation.
Until such changes happen and D becomes _a community process_ (as 
I see Andrei is rightfully pushing for) there is little chance of 
a bigger D success.

Also, just to touch the multiple compiler versions overhead you 
mentioned - The point of maintaining multiple branches is to 
_minimize_ such overhead, not increase it. This allows for easier 
management of features, a more gradual release process to prevent 
regressions and breakage on the release branch, it gives _more 
control_ and allows for scaling of management to more developers. 
more branches => less work for you.