Am Mon, 17 Mar 2014 03:57:10 +0000 schrieb "Jesse Phillips" <[email protected]>:
> On Sunday, 16 March 2014 at 21:15:29 UTC, Martin Nowak wrote: > > Please think hard about this. Why does it need to break code? > > Can't we have a proper deprecation cycle? > > Until now it was always possible to add proper deprecation > > warnings and allow people to transition code at their own pace. > > I'm optimistic a solution can be found here too. > > Deprecation is breaking code, it's a good way to to do it, but > you shouldn't kid yourself that it isn't a breaking change. It certainly is a subjective matter. I usually skim though the change log, install the new compiler and cross my fingers. Then if I get a few deprecation messages with IDE links to the source that's ok for me every two months or so. I just try to fix these locations immediately instead of changing the build options to include -d. Silent breaking changes are a totally different beast. But it certainly depends on time pressure, how much infrequently maintained libs you use etc. At the end of the day I see no way for D to evolve "correctly" with the man power it has and the demands for both a stable target and improvements to so many things from final-by-default over "scope" to "shared". If we collected all these bits in a list we would see that they can't all be fixed in one release and things are still going to break quite a few times in the future. TLBB? Not quite there yet! ;-) -- Marco
