Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.
To your question of software versions below is what we do. I'm not going to claim it's foolproof but this has worked best for us over other schemes we've been forced to use in the past by OEMs. Our software is OEMed by several major vendors and so a single code branch could become one to five different applications with the same build number. To avoid target confusion we point bugs against code branches and then track at release time what branch an application was released off of. We also tag sources every time an application releases of course. We don't tag ALPHAs or BETAs, only final releases. We do not do developer level branches - only formal company branches are allowed and that's worked OK for us. CVS branches are also known as "legs" around our office and we tend to go in alphabetical order. So our very first trunk, under PVCS a hundred years ago, was referred to as the "A-leg" and started with a branch name of Atlas (or something). A fresh architecture will tend to bump the leg letter (A-leg to B-leg) with in leg branches the second number and individual bug fixes impacting the final version number. So off the C-Leg, the trunk, we branched Carmen, Casper, Charly, Cooper, Cougar, Coyote, Crane, Creek, Crocus and so on. Each branch off the trunk represents a development wind down toward stability and the idea is that we should be able to ship a point release off branched code at any time. The trunk is where instability lives (currently referred to as Crown around the office). We moved to CVS from PVCS about a year ago and are still moving over from some PVCSisms in or development world. CVS's TRUNK is what we refer to as a leg pretty much but we still talk about an alphabetical leg name instead of "TRUNK" or "HEAD" when targeting features and bugs. It's a historical culture thing and our build system allows for labels and branches to be different so we can build "Darwin" as a label but the code comes off the D-leg "TRUNK". Anyway, this probably makes no sense since it's a pretty complicated subject and every development group is different. You're applications and release management requirements could be completely different than ours and probably are. Take this for whatever it's worth, there are lots of fine releases cycles out there. E.g. CVSNT and lots of open source uses the second triplet number for stable/instable. That you're looking into it early rather than later means you'll likely get something in place that'll work for you. Just don't forget bug and feature targeting - how do you target bugs? You do have a bug tracking tool right? --Aric Aric Czarnowski Unimax Systems Corporation 612-204-3634 -------------------- All our software now follows a standard version triplet and efforts should be made so that any new applications also follow this versioning scheme. The scheme is: a.b.c ALPHA/BETA d where: a is the major release number - bumped when new architectures are created, or functionality considered major by the customer or OEM partner is added. This often follows a code base "leg" letter change like from the C-leg to the D-leg for the open database architecture change. I.e., 5.X.X in the C-leg to 6.X.X starting with Darwin. This could also follow the release of new system support since any OEM partner would see that as a major release change. E.g. MSS support within Mailbox Manager meant a new 5.X release. b is the minor release number - bumped when there are minor functionality changes & bug fixes released to the customer or the OEM partner. This often follows an in-branch name change within a code leg (e.g. Creek -> Crocus) c is the patch number - bumped when the release is a patch release intended to address specific bugs. This represents an in-branch fix, e.g. an enhanced Crocus version. ALPHA - this term is left in place until whatever point "BETA" is decided to have begun. This point is different for each OEM partner relationship and customer pre-release cycle. BETA - this term is left in place until official release to the customer or the partner is made. d is the optional ALPHA or BETA version when that information is useful for clearer communication with the customer base or the partner. E.g., "When can we expect to see beta 3?" A typical release cycle could look like this, using a fictitious 10.x.x release as an example: 10.0.0 ALPHA first 10.0 very limited release alpha (new architecture) 10.0.0 ALPHA 2 second 10.0 very limited release alpha 10.0.0 BETA first 10.0 beta 10.0.0 BETA 2 second 10.0 beta 10.0.0 BETA 3 third 10.0 beta 10.0.0 initial general release of 10.0 to the public 10.0.1 first patch release of 10.0 10.1.0 BETA first beta of 10.1 (maybe a new system is supported) 10.1.0 initial general release of 10.1 to the public 10.1.1 first patch release of 10.1 10.1.2 second patch release of 10.1 11.0.0 ALPHA first alpha of 11.0 (a major change to the architecture) ALPHA and BETA releases are generally very informal things and not "officially" tracked and archived.