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)
