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

[Rob T]

On Thursday, 29 November 2012 at 19:53:13 UTC, deadalnix wrote:
> On Thursday, 29 November 2012 at 19:30:00 UTC, H. S. Teoh wrote:
>> Isn't this only necessary if the new feature depends on said 
>> breaking
>> changes? If not, it can be safely merged in. If it's a trivial 
>> change
>> like a syntax change, the stable maintainer can simply fix it 
>> by hand
>> and merge it in anyway.
>>
>
> New code means new bugs. This is why most project use the 3 
> numbers version. Eventually, if you add a new module to phobos, 
> people use it, and even if you don't you ends up using it 
> indirectly and you get the bugs.

The 3 number system is fine grained enough to do what we probably 
want.

If we use 3 version numbers like this: major.minor.revision, then

Incrementing "major" indicates a major release with breaking 
changes incorporated and/or new features added.

Incrementing "minor" indicates no breaking changes, no new 
features, but possibly new bugs were introduced due to the the 
changes that were made.

Incrementing "revision" indicates a bug fix only release.

We should also have 3 branches in principle, each corresponding 
to the 3 version numbers. One for stable, which receives only 
revision updates after major.minor is frozen, another for 
pre-stable and also for the "stable candidate" which frozen from 
new features, but uses same branch, and a 3rd for unstable, which 
eventually moves to pre-stable branch.

This is more or less how Debian seems to do it.

--rt