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

[Paulo Pinto]

On Wednesday, 28 November 2012 at 08:51:02 UTC, Dejan Lekic wrote:
> On Wednesday, 28 November 2012 at 01:38:38 UTC, SiegeLord wrote:
>> Another DMD alpha, another set of previously valid code that 
>> no longer compiles. With 2.060 it was the TypeInfo constness 
>> changes in druntime, with 2.061 it is the dissalowance of 
>> rebindability of the this pointer. The latter did make it into 
>> the spec half a year ago, but recently it was actually 
>> dissallowed in the beta. Unlike many other features of the 
>> sort (e.g. octal literals) there is no warning or deprecation 
>> errors... code that use to compile simply does not anymore.
>>
>> In this last case, in principle, we were lucky... the spec was 
>> changed. What about things like this: 
>> http://dlang.org/attribute.html#inout . Are those undocumented 
>> features liable to change at any time? What warning will there 
>> be when somebody decides to submit an inout bug and somebody 
>> else fixes it in a way that breaks existing code?
>>
>> D1 is scheduled to be discontinued in a month, and every new 
>> version of DMD keeps changing D2 in code breaking ways (or 
>> worse, with backwards incompatible spec changes). I think that 
>> unless people responsible for these things get their act 
>> together and stabilize D2 against these issues, D1 support 
>> should be extended until that happens.
>
> Now you understand why I stick to Java at work, and use D only 
> for non mission-critical (small) projects. If I know that the 
> project is going to have large code-base I *do not* use D (by D 
> I always mean D2).
>
> However, If I *had to* use D for a large-scale project I would 
> do the following:
>
> 1) Make my own fork of DMD, Druntime and Phobos, and maintain 
> them myself. Ie. merge only changes from the upstream that do 
> not break my own project.
> 2) Use these forked projects to build my project.
> 3) Periodically, when time permits, I "jump" to the latest 
> release of DMD, Druntime and Phobos. Naturally that would be a 
> big job, to fix my broken projects code. But as I said, I have 
> reserved a lot of time for this so I am fine with this.
>
> This is how it is done in real world mostly. I know I did it in 
> the past. I used an experimental branch of a certain C++ GUI 
> toolkit in a large project. I did exactly what I explained 
> above, and it was all right! :)

I fully agree.

This only works however, if the overhead is not too much and 
management is ok with it.

--
Paulo