Deprecated Library Functions / Methods

[Jonathan M Davis]

On Monday, December 03, 2012 02:49:39 Rob T wrote:
> I know that there are plenty of challenges to overcome wrt
> changing the way D is being developed and released, but to try
> and develop D using only one version for both stable and unstable
> is simply not going to work. It also will not work to lock down D
> and prevent it from improving in breaking ways overthe next 5
> years (or whatever).

There is still a considerable difference between a library which is intended to 
be stable and one which is under heavy development. We've essentially been 
working under a model where the API was fluid enough that we could break code 
as long as we gave enough warning first. We want to move to a model where the 
API is stable enough that code written now will compile 5+ years from now with 
no changes. We can still look at phasing out stuff that needs to be replaced. 
It's just that we then need to keep it around (even if it's deprecated and 
undocumented), whereas when the API is under heavier development, more 
permanent breakage has been permissible. For instance, std.date is dead and 
gone, having been replaced by std.datetime, and that was a good decision at 
the time given the level of stability of the library. But if we were to 
replace std.xml with std.xml2 now, we would need to keep std.xml around long 
term (even if it's deprecated and undocumented) so that code would continue to 
compile for years to come, because we've reached a point when we want to have 
a stable API that people can rely on rather than trying to clean up all of the 
little things that we were trying to clean up before.

So, yes having a development and stable branch will help manage things, but 
even with that separation, we don't want to be breaking people's code due to 
library changes.

- Jonathan M Davis