RE: Developing frameworks and applications in tandem and managing dependencies

Hi John,

> Thanks for the run down. How do you manage the build number? Do you just
manually edit it in a file?

Basically, yes. The build no. is generated from a version.h file in the root folder of the solution, and which is compiled into the resources. It looks a bit like this:

#define FILE_VERSION_NUM		4,0,0,183
#define PRODUCT_VERSION_NUM		4,0,0,0

#define PRODUCT_NAME			"Visual Lint"
#define FILE_VERSION                "4.0.0.183a"
#define PRODUCT_VERSION			"4.0"
#define LEGAL_COPYRIGHT			"Copyright © 2004-2012 Riverblade Limited. All rights reserved."

We bung an alpha suffix on the end of the build no. during each sprint to distinguish it from anything that should be released.

The usual sequence is something like:

4.0.0.183     (beta tester release)
4.0.0.183a    (internal spike build)
4.0.0.183b    (spike build)
4.0.0.183c    (spike build)
4.0.0.185 RC1 (release candidate)
4.0.0.185     (beta tester release)

The alpha suffix also allows us to produce patches when required.

We've thought of automating the whoe thing via the CI server, but it really doesn't gain us that much. At some point we must get around to linking  the FILE_VERSION_NUM and PRODUCT_VERSION_NUM fields with their string counterparts though.



Kind Regards,

                Anna-Jayne Metcalfe
                Product Manager,
                Riverblade Limited

                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 enquiries-Ql1sqIwY9iDiUBgd2R2O9eG/[email protected]

ACCU - http://www.accu.org - Writing software is a craft, and crafts need craftsmen. Where else are you going to learn?