Re: Practice: Single Code Base

GREAT story of how you eliminated the need for version-branching by 
deferring the feature-set selection logic to later binding time (run-time)!

It sounds kind of like Doug Schmidt's "Service Configurator" pattern. It 
also seemed somewhat reminiscent of home some license-managers work to 
lookup if a given feature is licensed for use by the current 
user/installation (particularly when the software supports multiple 
feature levels, say for eval/demo, home/personal-use, small-business, 
and enterprise).

So are some of your your previous development CM problems now arising as 
deployment (installation configuration) CM problems? Or are they new 
problems instead? I know what kid of problems your solution avoided, Im 
curious about your thoughts and experiences with the set of issues you 
"traded-off" for instead, how you resolve them, and how/why you feel the 
trade-off is worth it.

Andrew McDonagh wrote:
> Brad Appleton wrote:
> 
>>Hi Andrew!
>>  
> 
> Hi Brad,
> 
> snipped.
> 
>>
>>Thanks for the story (and the praise of the book :)
>>
>>  
>>
> My pleasure, your help in SCM matters have served me (and others) very 
> well indeed over the 8 years I've been a developer. Starting fro CCIUG 
> days to now.
> 
>>>There is a trade off, the 'branch'ing still exists, albeit in code
>>>rather than SCM, and so its just as possible to introduce bugs into one
>>>version but not another.  However, this is largely mitigated by because
>>>we can build and test each of them at the same time from a single source
>>>code base, rather than having to use the SCM tool's branching support.
>>>    
>>>
>>
>>Can you say more about what it means for the branching to be "in code 
>>rather than SCM" ? I didnt entirely understand and want to learn more 
>>about it.
>>
>>  
>>
> Sure...
> 
> As we know, typically different versions of the same product branch at 
> SCM level, by Branch I mean a 'Variant' code base (project-oriented 
> branching), based upon the previous version.
> 
> Mainline for Product
> 
>    0
>    |
>    1---1.1---.1.2--- 1.3 (no longer supported by company)
>    |
>    2---2.1 (only bug fixes and minor enhancements)
>    |
>    3 (Latest version of product - all singing all dancing best ever)
> 
> 
> The problem I've seen in other projects, has been to do with having to 
> support 2.0 & 2.1 whilst at the same time work on the latest version 3.  
> Bugs fixed in 2.0 have to be merged into 2.1.  If they exist in 3.0, 
> then they are merged there if possible, however, a lot of the time, its 
> not possible to merge the fixes between 2.x and 3.0 branches because the 
> code has moved on so much and so the fix has to be reimplemented.
> 
> Every now and a again we'll have one customer who wont upgrade to the 
> latest version of any of the offically supported versions (2.x), yet 
> still want and get support from the company - in these cases its a 
> business discussion as to whether we fix the issue the customer has, or 
> not and convince them to upgrade.
> 
> All this leads to the usual problems of fixes being applied to multiple 
> branch lines, and all of the associated work with those activities.
> 
> Having been burnt enough by this in the past I wanted a situation where 
> we could mitigate the need for duplicating the work, either through 
> having to merge the fixes/enhancements or simply having to re-implement 
> them afresh on each branch.
> 
> So how is this achievable when we still need to have the concept of 
> 'branching' the product - as we need to support differing functionality 
> for the various releases?
> 
> The options I came up with are:
> 
> 1) Branch within the SCM as above - nope
> 2) Branch at build time - using build parameters, #defines, 
> configuration scripts.
> 3) Runtime - using various patterns (Strategy, Command), config files 
> and behaviour registration techniques.
> 
> In our case, Runtime branching essentially uses a lot of build time 
> branchings support for creating/modifying any necessary config files - 
> although these could also be created/modified at runtime by the products 
> installation tool.
> 
> Within our application, there is a FeatureRegistry object that uses the 
> config files to determine what the product version is.
> Within the apps startup code, features are registered with the 
> FeatureRegistry and provide a minimum product version that they are 
> allowed to be used with.  This really is as simple as a product version 
> object and the features ID.
> 
> Then anywhere within the code that would make use of that feature, 
> checks the FeatureRegistry to see if the feature is enabled or not - the 
> FeatureRegistry simply checks the minimum version number against what it 
> thinks the product version is.
> 
> Using patterns like Strategy, Command, etc means we have a nice loosely 
> coupled design, which can change behaviour at runtime.
> 
> At present, there is no need to dynamically change the products version 
> number at runtime, but should we need to, then it wouldn't be to hard a 
> change to implement.
> 
> Its very much like how Java can change its look and feel at runtime, or 
> how a lot of products nowadays can have extra features enabled just by 
> buying a different licence key.
> 
> I believe (although I can't substantiate) the Quake game engine used a 
> simpler technique when they were developing Quake 2.  They did start 
> with a branch, the continued with the Quake 1 code and extended it and 
> used config files (the Maps basically). This led to quicker release 
> times and the ability to give Quake 1 patches for bugs they fixed as the 
> went along.
> 
> HTH
> 
> Andrew
> 
> 
> 
> ------------------------------------------------------------------------
> *Yahoo! Groups Links*
> 
>     * To visit your group on the web, go to:
>       http://groups.yahoo.com/group/xpbookdiscussiongroup/
>        
>     * To unsubscribe from this group, send an email to:
>       
> xpbookdiscussiongroup-unsubscribe-hHKSG33TihhbjbujkaE4pw@xxxxxxxxxxxxxxxx
>       
> <mailto:xpbookdiscussiongroup-unsubscribe-hHKSG33TihhbjbujkaE4pw@xxxxxxxxxxxxxxxx?subject=Unsubscribe>
>        
>     * Your use of Yahoo! Groups is subject to the Yahoo! Terms of
>       Service <http://docs.yahoo.com/info/terms/>. 
> 
> 

-- 
Brad Appleton <brad-777BKhlmzsrR7s880joybQ@xxxxxxxxxxxxxxxx> www.bradapp.net
    Software CM Patterns (www.scmpatterns.com)
    Effective Teamwork, Practical Integration
"And miles to go before I sleep" --Robert Frost