Re: Version Numbers

In article <[EMAIL PROTECTED]>
           [EMAIL PROTECTED] "Rob Horton" writes:

> Hi,
> 
> the other day I was pondering my methodology for creating new version
> numbers for my embedded products.
> It is very simple and is in the form A.B where A represents a big change and
> B represents a small change.
> 
> I got to wondering if there is a standard for version numbers. Does anyone
> know of any?
> 
> As an example, in Delphi, the version number is of the form A.B.C.D where:
> 
> A = Major version
> B = Minor Version
> C = Release
> D = Build

One I have seen in many places is the A.B.C (only three levels) where
A=Major
B=Minor
C=Trivial

However, none of those companies would agree how to categorise what each
of those meant in terms of the impact of changes.

Personally, I tend to link my embedded programming very closely with the
hardware it is to run on. The software even has a proper part number 
( and a mechanical GA drawing) to go with it for identification. If the 
functionality changes then it is a different part number. Changes that
are made to fix reported problems will increment the issue number. In
house suffix letter increments help to keep tabs on the versions in
the loop that have not yet passed the final review prior to issue. All
documentation carries the "Save Date" printed on it (whether paper or 
electronic format). Of course my process is simple and rigourously 
applied as befits building High Integrity Distributed Embedded Control 
Systems.

-- 
********************************************************************
Paul E. Bennett ....................<email://[EMAIL PROTECTED]>
Forth based HIDECS Consultancy .....<http://www.amleth.demon.co.uk/>
Mob: +44 (0)7811-639972 .........NOW AVAILABLE:- HIDECS COURSE......
Tel: +44 (0)1235-811095 .... see http://www.feabhas.com for details.
Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
********************************************************************