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 -

(replace nospam with esacademy to reply)

and

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

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

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

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX

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

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

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 ....................
Forth based HIDECS Consultancy .....
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..
********************************************************************

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.

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

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

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."
    "I am big.  It's the pictures that got small."

Hi Ken,

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.

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.

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

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

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.

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 (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
     USE worldnet address!

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

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 hopefully 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

of

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.

3.01 3.06 3.60

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

Ralph