RE: Developing frameworks and applications in tandem and managing dependencies

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?