Versioning best practices

[Lars Ivar Igesund]

I've been looking at what D and the compilers provide to help with
successfully versioning D source code in such a way that it minimizes
duplication of code (and in the process ease organization of said code),
ease readability and ease building.

As it is, D provides several tools, but they seem to me to be somewhat
disjoint. What I'd like to hear, is if there is a combination of the
existing features (that makes sense) that will achieve the above to at
least some degree.

First, what is versioned and thus may affect the application builder:
* The compiler, e.g. DMD 0.178, 1.00, 1.001, GDC 0.20, 0.21
* The specification, currently only D1.0 (there may be issues with this, but
I won't go into it here)
* Libraries having their own release schedule (and which probably depend on
one or both above in some fashion)

The tools:
* version statements - This is a very good feature for separating the
features of the application or the library, but requires the set versions
to be passed through the command line
* std.compiler - This module contains all the relevant version numbers;
compiler, spec and also the vendor. These numbers can not be used in the
version statements.
* static if - a very useful feature that can compile in parts of the code
using the numbers in std.compiler, but if that is a suggested solution,
then it _really_ should be possible to use these constants in a version
statement.
* the -v1 switch - this is to make sure that D code complies to the D1.0
spec, but does this mean that code that is conditionally excluded (for
instance because it is post D1.0 code) need to syntactically comply to
D1.0?

Problems:
A couple are mentioned above, especially that values in std.compiler cannot
be used in version statements. A possible solution to this, would be that
the compiler defines these as preset versions, but then again currently
only one (and unnamed) integer version can be supplied, and it is not
possible to say that you want the spec version to be >= D1_0 (or a similar
preset version identifier).

Does this mean that one really should not version code (in the source) on
any of the above criteria (compiler version or spec version)? I'm not
necessarily opposed to this, as after some versions, there will be a lot of
statements and may become hard to manage.

The alternative is (afaics) to use a version control system and actively tag
revisions as the need arise, and then properly document which versions of
what are supported, and possibly provide a more complex build setup (maybe
even something akin to autoconf).

As was mentioned in some other thread, now that the new GC (supposedly not a
breaking change) is not working properly, the current versioning scheme of
spec and compiler, still seems somewhat raw.

Do you think that the current tools are adequate?
What would then be the best way to use them?
Can we still refine conditional compilation to make some of this
easier/better looking?
Are there other problems or tools (I'm mostly talking about language and
compiler features here, not external tools, although that may be part of
the solution) that I have not mentioned that should be considered?

I believe some of the above are more of an issue in D than in other
languages, partially because the tools may not be sufficiently useful, but
also because D is as of yet a fast moving target.

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource & #D: larsivi
Dancing the Tango