D versionning

[SomeDude]

On Thursday, 12 July 2012 at 17:20:32 UTC, deadalnix wrote:
> On 12/07/2012 19:10, Tobias Pankrath wrote:
>>> The system adopted in PHP works with a 3 number version. The 
>>> first
>>> number is used for major languages changes (for instance 4 > 
>>> 5 imply
>>> passing object by reference when it was by copy before, 5 > 6 
>>> switched
>>> the whole thing to unicode).
>>>
>>> The second number imply language changes, but either non 
>>> breaking or
>>> very specific, rarely used stuff. For instance 5.2
>>> > 5.3 added GC, closures and namespace which does not break
>>> code.
>>
>>
>> We can also learn from the python community, whose from 
>> __future__
>> import <feature> facility is a great success and we should 
>> adopt a
>> similar scheme.
>>
>> Consider the -property switch or a future introduction of 
>> tuple syntax.
>> If you start a new project, it's no problem. Just use the 
>> switch and don't
>> introduce things that will not work without. But if you have 
>> an old
>> codebase
>> but want to use a new feature you can either
>>
>> a) fix the hole codebase at one
>> b) fix and configure your build systems to build some files 
>> with and
>> some files without the switch.
>>
>> Both options are PITA. An alternative is to introduce 
>> #pragma(future,
>> tuplesyntax);
>>
>> Now you can insert the pragma in those sourcefiles that are 
>> new or
>> already fixed and you can immediately benefit from the feature 
>> and you
>> can upgrade your code file by file or even scope by scope.
>>
>> Later versions could even introduce #pragma(past, 
>> notuplesyntax) before
>> dropping the old syntax completely.
>>
>
> This scheme don't allow for breaking change to be made. It also 
> require the compiler to handle a mess of features that can be 
> activated or not. This is way more work, and I don't really see 
> the benefice.
>
> As non breaking change are introduced in a different process 
> than breaking one, it is easy to migrate to new version that 
> will not break legacy code and provide new features.

OTOH, it may break the community yet again, which we certainly 
don't want, probably even less than breaking code.
Also, the example of Python with two main stable branches that 
live in parallel is not very encouraging.