Version Numbers

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

Translate This Thread From English to

Threaded View
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

So does that mean we can have different releases of the same version? But
then surely a different release will be a different version?
Should build be incremented each time a project is compiled?

(please note, this isn't a Delphi specific question. I only used delphi as
an example.)

What sort of system do "you" use?

Cheers.

Rob.



Re: Version Numbers
A.B

If I make some bug fixes or minor changes or add a small number of feature
additions, I increment B.
If I add a lot of new features (lot = maybe 6 or more) and/or make a
significant reorganization of the user interface and/or make significant
changes in algorithmns which could affect operation then I increment A and
set B = 0. :)
However, if I reach 99 with B then on the next minor change I guess I would
increment A and set B = 0. Hasn't happened yet, but soon will with a
specific piece of software I have been maintaining for a while.

Andy
Embedded Systems Academy - www.esacademy.com
(replace nospam with esacademy to reply)

Quoted text here. Click to load it
and



Re: Version Numbers

Quoted text here. Click to load it

This is not a full answer to your question, but many years ago I worked
in a small company where all manufactured components items had 6 digit
part numbers.  A firmware chip set was 56xxxx.  I appended a version
number, A, B, ..., to indicate fixes.  If the nominal function was the
same (as described by the documentation), the base number remained the
same.  If the functionality was changed, the base number was changed.
In theory, there was no risk in going up a rev with the same part
number.

The point is that there was a part number distinction between functional
changes and only fixes.  Functional enhancements could go either way if
they had no effect on the earlier functionality, but simply allowed new
functions.  My tendency with enhancements, though, would be to assign a
different base number with supporting documentation that described the
enhancements.

Thad

Re: Version Numbers

Quoted text here. Click to load it
and

There is none. I *always* include a date in my build numbers. It is good
practice to include remarks in the program regarding the changes that you
are making. It is also a good idea to put something in your program, if you
can, that can respond to a particular command with the build number. -- Mike



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

Of all the places I have worked, I have not found much commonality in
how they indicate versions.  The A.B.C.D system above seems redundant.
Either you track your builds with numbers or you track releases with
numbers, but why track both in one huge number?  

I think the other posters have it approximately right on the A.B
number.  A is incremented anytime you make a change that affects the
interface or functionality so that you need to update the
documentation.  B is incremented any time you make a change that does
not increment A and of course is reset to 0 or 1 when A is incremented.  

If you are just fixing a bug that will not affect external circuitry (or
the user), then only B is incremented.  But if your change requires
attention outside the unit, then A should be incremented.  This is
easily judged by whether you need to make adjustments in the
documentation.  


--

Rick "rickman" Collins

snipped-for-privacy@XYarius.com
We've slightly trimmed the long signature. Click to see the full one.
Re: Version Numbers
Quoted text here. Click to load it

A = new product (ie Mark 2)
B = new feature
C = bugfix / optimisation / cosmetic

Instead of a build number I get the compiler to embed the build time and
date.

Regards,
Mike.

--
Mike Page BEng(Hons) MIEE           www.eclectic-web.co.uk


Re: Version Numbers
On Wed, 19 Nov 2003 19:19:43 +0000, Mike Page

Quoted text here. Click to load it

We used to do this  but found it more of a hinderance rather than an
assistance. If you use a source version control system (as we do) it
meant that you could never re-build an identical system (from the
sources) that was used for verification & validation -- the checksum
or CRC would always be different. Also the build time & date is
actually a bit useless as it doesn't really reflect the chronological
maturity of the software -- a "last modified" date & time would be
more useful.

Quoted text here. Click to load it


+====================================+
I hate junk email. Please direct any
genuine email to: kenlee at hotpop.com

Re: Version Numbers
snipped-for-privacy@noname.com (Ken Lee) writes:

Quoted text here. Click to load it

There's a difference between production builds and in-house
development or research builds, but all need to be distinguised.  Ie,
I may want to make an experimental change, then give it to QA and ask
if they can compare the performance to the baseline.  Assigning a
separate release number just for that purpose is overkill.  We
typically added a developers initials as a suffix, as in "2.0.5-XYZ",
so that you could instantly spot who was responsible.

--
Darin Johnson
    "You used to be big."
We've slightly trimmed the long signature. Click to see the full one.
Re: Version Numbers

Quoted text here. Click to load it

No argument with what you've said, but in the context of the thread, I
can't immediately see how date stamping the build is advantageous.
Even with experimental builds, you may want to backtrack in case
you've broken something. If your software deliverable is made up of
multiple sources, then tracing back to a particular date/time could be
a pain.

Quoted text here. Click to load it

I presume we're talking cross -purposes as this is what I would
advocate also.

Ken.

Quoted text here. Click to load it


+====================================+
I hate junk email. Please direct any
genuine email to: kenlee at hotpop.com

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

I use Major, Minor, Build

Build is automatically incremented each time the code is built.

Version is proceed in the rom be an easily findable string ($VER) with a
byte for major, byte for minor, two bytes for build.  This way it's easy to
tell the version of a rom file, and the software can automatically update
it's self.

Version is always obtainable from the actual item in some human decodable
form or another.

I used to put the date in there, but in eventuality, we were only interested
in the relative newness of one build over another.


Ralph



Re: Version Numbers
           yahoo.com@mr_horton "Rob Horton" writes:

Quoted text here. Click to load it

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.

--
********************************************************************
We've slightly trimmed the long signature. Click to see the full one.
Re: Version Numbers

Quoted text here. Click to load it

In some ways it's not significant. All I can suggest is to adopt a
system that works well with your chosen source version control system.
Also if the version number is to be viewed by the customer, then I
would devise a system that was obscure yet trackable. Obscure in the
way that the customer doesn't immediate realise whether the software
is a major, minor, beta or alpha release.

Ken.

+====================================+
I hate junk email. Please direct any
genuine email to: kenlee at hotpop.com

Re: Version Numbers
Hi Ken,

Quoted text here. Click to load it

Why would you want to conceal this information? (Not being
argumentative; I really want to know).

I explicitly document firmware revision numbering systems precisely so
that the end-user will understand what s/he is running. I don't want
people assigning the same trust level to alpha/beta/special-build
versions as to official releases.

Re: Version Numbers
snipped-for-privacy@larwe.com says...
Quoted text here. Click to load it
I can think of a few reasons to do so.  I agree about the trust level
assigned to beta and other special releases, but there can be smaller
releases that occur to change the way a function is implemented or to
accomodate hardware changes.  While it is certainly necessary to be able
to track those differences it may not be useful for the end user to know.  

Getting back units from the field that have to be cracked open to patch
in circuitry and upgrade the firmware (maybe soldering and
desoldering an EPROM) since the LED driver you had been using was
obsoleted and had to be changed to a different one is at the very least a
waste.  And it is likely to result in a less reliable unit rather than
more.

I'm not sure that glossing over the change is the right way to approach
this kind of change but I can understand why it would be done.  For that
matter a lot of (most? all?) semiconductors companies reserve the right
to "improve" their devices without notice and in practice some are better
at keeping their customers informed about changes than others.

Robert

Re: Version Numbers

Quoted text here. Click to load it
and

1.2, where 1 is a big change, 2 is a small change.

Big change means a release to customers, or major change to specifications
or hardware.  Small change is used to keep track of versions during
debugging.




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

A = Major version: Incremented on requirements change; B and C are reset
B = Minor Version: Incremented on design change: C is reset
C = Release: Incremented on implementation change
D = Build: Continually increment, never reset

Re: Version Numbers
snipped-for-privacy@aol.com (Dingo) writes:

Quoted text here. Click to load it

Where does the knowledge of the build number ever come in handy?
If you've already got a Release number, the different builds should
not be different (if you change anything in the production build
process then the release number should change also).

--
Darin Johnson
    I'm not a well adjusted person, but I play one on the net.

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

You could leave the source unchanged, but change the compiler and
libraries used.  It will probably no longer be binary identical.

My first action when trying to attack some misbegotten monstrosity
is to generate an identical binary.  That way I have a known
starting point.

--
Chuck F ( snipped-for-privacy@yahoo.com) ( snipped-for-privacy@worldnet.att.net)
   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

I think that would (probably) be such a big change to the
final software I would change the major version number,
or, at least, the minor one.

I usually use the A.B system but sometimes I just use
a single 8 bit number if all I can do is flash the version
number on an LED or beep it from a sounder.

Mike Harding


Re: Version Numbers

Quoted text here. Click to load it
...

Yes, but in such a situation I'd think that the revision number should
change.  Normally the build system needs files modification (new
Makefiles), but even if they don't changing revision make sense.
At the very least, determining the exact sources _and_ build
configuration should be possible just from the version number.
Automatically incrementing the build number doesn't seem to provide
extra capability beyond this.

--
Darin Johnson
    Support your right to own gnus.

Site Timeline