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

Paolo Invernizzi via Digitalmars-d digitalmars-d at puremagic.com
Sat Nov 29 04:07:41 PST 2014


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




More information about the Digitalmars-d mailing list