... snip ...
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 (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
Available for consulting/temporary embedded and systems.
USE worldnet address!
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 2.5.2.36 and 3.2.1.57 are out in the field and a bug is found that affects both of them, having the next revision numbers be 2.5.3.58 and 3.0.2.59 is valuable.
...
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.
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
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.
I presume we're talking cross -purposes as this is what I would advocate also.
Ken.
+====================================+ I hate junk email. Please direct any genuine email to: kenlee at hotpop.com
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.
John
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.