Re: Developing frameworks and applications in tandem and managing dependencies

Hey Anna-Jayne,

Thanks for your lightening fast reply. I have a few questions because I
didn't entirely understand what you told me. I won't ask all of my
questions in one go though, so firstly:

Are you using Subversion as your version control system?

Regards,
John Elliot.

On 2012-07-31 18:26, Anna-Jayne Metcalfe wrote:
> Hi John,
> 
>  
> 
>> What I can't decide on is how I should accomplish this with my version
> control system.
> 
> We hit the same issue ages back with our core libraries, and decided that
> the trade-off is effectively whether you keep the product code stable or the
> core.
> 
> As we felt that multiple copies of divergent product code are less likely to
> cause issues (product branches tend to have a limited lifespan) than
> divergent versions of the core framework, we chose to allow the framework to
> remain common, and let it cause breaks and instability elseware to allow us
> to ensure that the product code always reflects the current framework
> design. 
> 
> A bit of background might help.
> 
> We have four products (Visual Lint, Visual TICS, ResOrg and LintProject Pro)
> which use the same core libraries. Of those Visual Lint is by far the
> largest (about 360kLOC in 45 projects - a lot of which is obviously test
> code and core libraries), and tends to drive development of shared projects
> most of the time.
> 
> Each product has at least two long term branches - Dev and Release. Dev code
> is unstable and (build from Dev are generally shared only with beta
> testers), while Release code is stable and reflects public versions of the
> product.
> 
> The way we solved the problem was straightforward - we placed a copy of each
> required library in each product, and linked each copy so that changes in
> shared code in one Dev branch are immediately reflected in all other Dev
> branches using it.
> 
> In a conventional build environment, that would seem to be a terrible idea
> as subtle breaks could lie undetected for long enough to cause major
> disruption at critical moments. However, as we use a continuous integration
> server (nothing fancy - just a simple CruiseControl.NET instance) breaks are
> detected and fixed very quickly.
> 
> As a result, Dev versions of all products are always being tested against
> the latest version of the core libraries, and always reflect their current
> state.
> 
> Release branches are another matter. They must be stable, and as such they
> are branched from Dev upon the first public release of a new version and
> then sandboxed from changes to it. Changes to core libraries there tend to
> be hand merged from the corresponding Dev branch where needed, and only live
> as long as the next product version release (which replaces the branch with
> a new one).
> 
> I hope that helps.
> 
>  
> 
>  
> 
> Kind Regards,
> 
>  
> 
>                 Anna-Jayne Metcalfe
> 
>                 Product Manager,
> 
>                 Riverblade Limited
> 
>  
> 
>                  <http://www.riverblade.co.uk/> http://www.riverblade.co.uk
> 
>                Twitter: @annajayne
> 
>                Skype: anna-jayne.metcalfe
> 
>  
> 
>  
> 
> Riverblade Limited, 3 Wellington Road, Bournemouth, Dorset BH8 8JQ, United
> Kingdom
> 
> Registered in England no. 5187132. VAT Registration no. 847 0045 38
> 
> Please direct general enquiries to  <mailto:[email protected]>
> enquiries-Ql1sqIwY9iDiUBgd2R2O9eG/[email protected]
> 
>  
> 
> ACCU -  <http://www.accu.org/conference> http://www.accu.org - Writing
> software is a craft, and crafts need craftsmen. Where else are you going to
> learn?
> 
>  
> 
>