dmd 1.069 and 2.054 release

[Adam D. Ruppe]

Jonathan M Davis wrote:
> The current plan is that _everything_ which gets deprecated will
> be removed.

What's the reason for removing things? Surely it's not disk space!


Anyway, let's look at the three categories. While I hate change,
there are two kinds of change: trivial and painful. Remember, D
isn't a useless piece of junk dynamic language - trivial changes
are easy to find and easy to change with confidence.

Painful changes though, are, well, painful.


> 1. Renaming stuff to follow Phobos' naming conventions.

These are trivial, just change it. It's like ripping off a band-aid.
The compiler will tell you what broke and how to fix it (the spell
checker ought to catch camelcase changes without keeping the old
name).

Do it fast, feel the brief pain, and move on.


> 2. Small redesigns of older functionality.

These should be reasonably trivial fixes too, but might warrant
deprecating the old on a case by case basis. If it's mindless
to change though, just rip that bandage off.

Just make sure that the types are different or something, while
still super easy to change, so the compiler will point it out to you.


> 3. Full module redesigns due to the need of serious improvement

This is where the pain comes in, since instead of spending 15
minutes running a mindless find/replace when the compiler tells
you to, it requires gutting a lot of code and rethinking it,
converting databases, etc.

These should ideally aim to redesign the internals, but keep the
same interface. Maybe adding to it or writing the old as an
emulation layer over the new.

This is preferred, since then new and old exist together. It avoids
actually breaking anybody's code.


If that's impossible though, this is the most likely candidate
for deprecation. Unlike a name change, it isn't easy to change,
so a compile error is more likely to mean reverting dmd versions
than actually changing it.