Version Numbers - Page 2

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Re: Version Numbers
Quoted text here. Click to load it

It serves the same purpose as a key value does in a relational
database (which it actually is in our build database). It's much
easier to refer to Build 168 than Revision 3.3.8.  It also indicates
a sequential value.  If revisions and are out
in the field and a bug is found that affects both of them, having
the next revision numbers be and is valuable.

Re: Version Numbers
Quoted text here. Click to load it

Mostly I have used the "Major.Minor" system where Major is incremented
for a new feature set and Minor is incremented for a bug fix.

It seems that everyone, including myself, uses a decimal point to separate
the major and minor revision numbers.  How do you deal with the confusion
that results when you minor revision number gets into double digits?  For
example, which build is more recent V3.10 or V3.6?

Currently we put leading zeroes on all minor revision numbers so the
previous example revisions would be V3.010 and V3.006.  We use three
digits because the minor revision is a byte with a max value of 255.

But, the leading zeroes still leave room for confusion because when people
speak the version number, some say "three point ten" while others say
"three point oh one oh".  I'm trying to get used to saying "dot" instead of
"point" to help clarify that the minor revision is not a fraction.  Then
people won't feel the need to speak the leading zeroes.

On future projects I may switch to "Major-Minor" or some other separator
character other than a decimal point.

 -- Kevin

Re: Version Numbers

Quoted text here. Click to load it

We use major minor in a 16bit int, low byte is minor, high byte is major
(followed by 16bits of build number).

Build number always goes up, simple.  The rest is all formatting.

%02i seems like it should fix your problem.


breaks down after 99 but then - do you really want to make more than 99
minor releases?


Re: Version Numbers
Quoted text here. Click to load it
... snip ...
Quoted text here. Click to load it

I slop everything into one number, with minor and 'fix' levels
limited to single digits, found by number modulo 10 and number/10
modulo 10, etc.

Chuck F ( (
   Available for consulting/temporary embedded and systems.
We've slightly trimmed the long signature. Click to see the full one.
Re: Version Numbers

Quoted text here. Click to load it

The seperator is a minor issue.  What's important is that you can
distinguish things.  The separator usually only shows up in
documentation, whereas flashed onto the product would be a binary
representation instead (one byte for major number, one byte for minor
number, etc).

Also important is external version numbers versus internal numbers.
Ie, the development cycle will invove it's own release cycles.  Thus
adding some extra suffixes can help there.  The customer may only see
version 1.5, but internally there may have been 10 revisions to get
to there from version 1.4.  You may also want to distinguish
development releases from QA releases (ie, the QA releases are
candidates for the final product, so bug fixes may be allowed but no
new features or integration).

Darin Johnson
    "Look here.  There's a crop circle in my ficus!"  -- The Tick

Re: Version Numbers

Quoted text here. Click to load it

We treat hardware, firmware, FPGA designs, everything the same way:
drawing number and rev letter. If the functionality is different, it
needs a new drawing number; if it's a revision with the same basic
function, bump the letter. This is classic aerospace document control.

Every drawing+rev is formally released to our company library before
it can be used for production or shipped to a customer; only the
manufacturing organization can ship. The library release includes all
required files to rebuild the end-item, including a readme.txt file
summarizing the situation, and all tools.


Site Timeline