Breaking compatibilyt hurts

[Nick Sabalausky]

"Leandro Lucarella" <llucax at gmail.com> wrote in message 
news:20091204133103.GB27013 at llucax.com.ar...
> Daniel de Kok, el  4 de diciembre a las 09:38 me escribiste:
>> On 2009-12-03 01:13:13 +0100, Jesse Phillips <jessekphillips+D at gmail.com> 
>> said:
>> >This has come up as one issue for adoption to D. D2.x is on its
>> >way, unstable, and D1.x is getting the ax. While Walter has said
>> >that the compiler will continue to get support, no one in the
>> >community knows what the library support will be like. I came
>> >across an article where even Python wasn't chosen for a project
>> >because of the eminent release of Python 3. He also dismisses Ruby
>> >and Clojure for other complaints people have expressed about D.
>> >
>> >--  
>> >http://postabon.posterous.com/why-i-chose-common-lisp-over-python-ruby-and
>>
>> It's just one opinion. Others will use Python, because Guido van
>> Rossum is not afraid to fix, change, and improve things, even in
>> point releases.
>>
>> I'd rather see D follow the Python path in this respect after D2 is
>> finished, than the C++ 'the world freezes' approach. At times, it is
>> inconvenient, but it also keeps a language and its library vital.
>
> But Python is extremely careful not to break backwards compatibility from
> one release to another. Breaking changes are usually introduced in
> 2 steps. In the first release with the new feature, the feature is
> optional and activated *only* explicitly through:
> from __future__ import feature
>
> If a feature is removed, it's deprecated (issuing a warning) in the first
> release.
>
> The second release with the change has the new/removed feature. That gives
> people time to fix their programs and try the new feature without breaking
> anything for several months (a minor Python version is released each ~9
> months aprox.). I certainly hope D2 doesn't follow the D1 path (before D2
> was forked), introducing new features each release without notice and
> breaking backwards compatibility.
>

If you're not ready for a breaking change, why not just stick with the older 
version until you're ready? Seems a lot simpler.