On Sunday, 24 February 2013 at 19:45:26 UTC, H. S. Teoh wrote:
Alternatively, use a version identifier:
version = newStdProcess;
import std.process; // get new version
-----
//version = newStdProcess;
import std.process; // get old version
Then once the old version has gone through the deprecation
cycle and is
kicked out, the new code can just ignore version=newStdProcess
and
always import the new version, and existing user code needs no
changes.
Would work just fine, *if* versions propogated across modules,
which they do not. (And doing so creates new problems discussed
to death and beyond in times past.) But maybe you meant setting
it at the command-line, which to be honest, was my first thought
as well. The ensuing discussion baffles me.
How about this as a suggestion, even though I know it will never
happen.
Release A:
- New process module is available as 'future.process'
- Old module remains available as 'std.process' but with a
pragma(msg) warning users that it will go away next release.
(It'd be even better to have a pragma(warn), actually.)
- Old module is duplicated as 'past.process'
Release B:
- New module is now 'std.process', but with a pragma(msg)
reminding users to update code if they haven't already
- Old module remains at 'past.process'
Release C:
- New module remains at 'std.process' now with no special
messages.
- Old module remains at 'past.process' for the last time.
Ta, fricking, da.
We should have started a procedure like this ages ago for Phobos
additions and rewrites. Not everyone is in a position to
comfortably use pre-release compilers, so testing new code from
git head is not an option for them. Further, this gives old code
three whole releases before it's forced to update; that ought to
be enough legacy support.
Legacy support is the devil.
