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
