Phobos - breaking existing code

[Jonathan M Davis via Digitalmars-d]

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