On Saturday, November 29, 2014 10:46:14 Daniel Murphy via Digitalmars-d wrote: > Two years is too old, you skipped all the deprecation stages.
That's pretty much the long and short of it. The deprecation cycle for stuff in druntime/Phobos is currently about two years long (one year as deprecated and documented, one year as deprecated and undocumented). So, anything that had been in the deprecation cycle when Walter last touched that code would be long out of it by now, and depending on when the releases really fell vs how close to two years it's really been, it wouldn't be that hard for some stuff to have started and completed the deprecation cycle since the last time he updated that code. We haven't even been trying to make it so that code can be unmaintained for two years and then still build with no changes. It's pretty much been the expectation that anything untouched for that long is essentially dead. We don't deprecate anywhere near as much stuff as we used to or do it anywhere near as frequently, but two years is long enough that you're going to skip the entire deprecation cycle for stuff. We can certainly look at increasing the length of time for the deprecation process, but that creates more cruft in the library, increases the risk of symbol conflicts and makes for more code to maintain - code that shouldn't even be used anymore. The primary solution has been simply to raise the bar for what changes we'll accept that will result in deprecations. But they still happen sometimes if the change is deemed worthwhile enough (in particular, it sounds like Walter's big problem is that std.path was redone a while back, which was definitely more than simply renaming stuff). And the only way to outright prevent code breaking due to changes like this, we'd have to keep deprecated stuff around indefinitely, which is a maintenance problem. I'm not completely against increasing the length of the deprecation cycle in order to reduce the risk of code breaking without notice when it's not actively maintained (e.g. from two years to three), but I also don't think that it's completely reasonable to expect that code which is untouched for two years will work with the latest compiler and library. Not even the language itself is that stable, and it's a _lot_ more stable than it used to be. I completely agree that we should be trying to reduce code breakage even over longer periods of time (and I think that we definitely _have_ reduced it, even if it's not by enough to allow Walter to compile his two year old microemacs code without using any compilers in between), but I also think that the expectation that old code should compile several years later with no changes and without using any compilers in between is higher than reasonable. I'm not sure that that even works with C++ compilers, much as it should - especially when you go from C++98 to C++11 or C++14, and since D is continually in flux (even if it's a lot less flux than it used to be), doing something like going from 2.058 to 2.066 is a lot like going from C++98 to C++11. To really have full stability, we'd pretty much have to freeze everything and change nothing beyond bug fixes, and we're definitely not doing that. Heck, simply introducing a new function to Phobos can break existing code, because it can create a symbol conflict. It's an easy fix, but stuff like that makes it nigh on impossible to guarantee that we won't break two-year old code. - Jonathan M Davis
