On Friday, 28 November 2014 at 23:38:40 UTC, H. S. Teoh via
Digitalmars-d wrote:
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.
T
Well said. I don't know any "sane" software company not being
ruled by a process like that.
Here in SRLabs we are sticking with what you have described, with
one variation: one person (and only one), it's constantly trying
to build a branches of the projects with the latest compiler,
testing our internal pull requests.
Many bugs are avoided, as detected by more recent compiler
version, and it's very rare not being able to keep the pace with
the other developers.
From time to time, during the development of some product, we are
so confident by the state of the "unstable" to just jump everyone
to a more recent compiler version.
But when the product is released, we stick with the version of
the compiler used to release it, till it's end-of-life.
---
Paolo
