2 types of D users, both can live together happily if we adjust

[H. S. Teoh via Digitalmars-d]

On Fri, Nov 28, 2014 at 11:06:14PM +0000, Mike via Digitalmars-d wrote:
> On Friday, 28 November 2014 at 20:20:55 UTC, ketmar via Digitalmars-d wrote:
> 
> >this has an easy solution: just stick with the chosen D version:
> >nobody forces anyone to upgrade.
> 
> Amen.

Yeah, it's not wise to keep upgrading the compiler, even in C/C++, since
many enterprise products tend to exhibit subtle breakages with new
compilers. (You may have heard of Linus ranting about newer versions of
GCC that "miscompile" the kernel, for example -- I remember back in the
day, the word was that you had to use egcs to compile the kernel,
otherwise if you get a kernel panic you're on your own, the devs can't
(and won't) help you). The code that I work on in my day job has a lot
of compiler-specific hacks, and would *certainly* become unusable if we
were to build it with a non-standard compiler -- standard being what's
shipped in the development environment that we are required to use for
building it, which hasn't changed for the last 5 years at least (so it's
definitely *not* a new compiler!).

Of course, being stuck with an obsolete version of D is Not Nice, so one
idea that occurs to me is to do infrequent, preplanned upgrades.

For example, say you standardize on dmd 2.066 for the current product
release. This means that you will *only* compile with 2.066 and nothing
else, and developers are required to use only the "official" compiler
version for their work.  This also means that you, being the boss,
decide what feature sets are / aren't allowed in your codebase. For
example, glancing over Google's C++ style guide, many C++11 features are
banned outright -- even though ostensibly they must have *some* value to
*somebody*, otherwise they wouldn't be in the spec! So basically, you
decide on the compiler version and feature set, and stick with that.

Now, the product may take a long time to develop, ship, and maintain, so
by the time it's in maintenance mode, it could be several years from
now. By then, upstream dmd may already be at 2.074, say, but your
codebase is still only 2.066. At some point, you'll want to upgrade --
but that should be done wisely.

Never ever upgrade your mainline development wholesale -- if you run
into problems (e.g., a language feature you depended on has changed and
it's non-trivial to update the code to work around it) you don't want to
find yourself in the unpleasant position of having a non-working
codebase. Instead, start out a pilot branch with one or two dedicated
developers who will (attempt to) build the code with the latest
compiler. If you're extremely, extremely, extreeeeeemely lucky, all goes
well and you can run some unittests, then some controlled field testing,
then switch over.

More likely, though, you'll run into some issues -- compiler bugs that
got fixed and code that relied on that is now broken, etc.. So you take
the time to investigate -- on the pilot branch -- how to work around it.
Once everything is figured out, start investing more effort into porting
the codebase over to the new compiler -- at the same time evaluating
possible new feature sets to include in your list of permitted features
-- while still keeping the 2.066 compiler and the original branch
around. Don't ever throw out the old compiler until the older product
release is no longer supported. Ideally, the new branch will coincide
with the next major release of your product, which should give you some
time to sort out compiler bugs (new and old), language workarounds,
etc.. Once the new release is stabilized enough to be shippable, you can
start deprecating the older codebase and eventually drop it.

Basically, this isn't too much different from what you'd do with any
other 3rd party product that you depend on -- you never just drop in a
new 3rd party release with no planning and no migration path, that's
just asking for trouble. You always keep the current environment running
until the new one has been proven to be stable enough to use, then you
switch over.


T

-- 
"Outlook not so good." That magic 8-ball knows everything! I'll ask about Exchange Server next. -- (Stolen from the net)