Version Scheme Proposal:
- Product#: [16-Bit Word] A number identifying the intended set of functionality (i.e. the classification of requirements: ERF, ZCPU, PC Test Stand, DeviceNet Comm Driver Library, etc.) (hand-selected, unique number)
- Major: [MSB of Major/Minor 16-Bit Word] 'From-scratch' version number indicative of an entire new set of requirements for either the module or project
- Minor: [LSB of Major/Minor 16-Bit Word] Changes have been made to FUNCTIONAL requirements (resets when Major version increments)
- Revision: [16-Bit Word] Number of times the artifact/module has been FULLY and SUCCESSFULLY tested and approved for release (this covers changes in non-functional requirements as verification of these would be covered under testing). (resets when Minor version increments)
- Build: [16-Bit Word] Continuously incremented when an artifcat/module is built and 'sent' for testing (never resets)
(OR [Product#].[Major].[Minor].[Rev].[Build] if preferred)
- Product: [1 Byte] The overall classification for a given set of high-level requirements (i.e. DCE, SPR, TE)
- Release: [16-Bit Word] The incremental number used to identify a complete set of modules which have all been individually approved for release and have undergone acceptable integration testing and approved for release as a known, demonstrated configuration (never resets and is never reused within the same product line)
Note: numeric size suggestions are suggested as minimums for consideration in non-string version identification communications
Feature request: The CEO of Toy Barn asks us to make the Menacing Toy Tank we supply them more dangerous by making the speed at which it travels less predictable.
Functional Requirement Update: The SWEE team updates the requirements (or User Stories) of the Menacing Toy Tank Chassis Control Subsystem to include a 'Randomize Travel Speed' function and a couple supporting characterics. Since this directly affects a module within the product, the Minor version number of the Chassis Control Subsystem module will be incremented.
Artifact Revision: Robert Mitchum updates the Chassis Control library to include this new function and increments the Chassis Control library's Build number (to the next ODD number). He then updates the Menacing Toy Tank's Main Control application to use the recently added function and increments the Main Control application's Build number (to the next ODD number).
Successful Testing: The Cloak test's Mr. Mitchum's changes against the updated specifications and upon passing all tests, he increments (or instructs Mr. Mitchum to increment) the Revision numbers of both modules, also incrementing the Build numbers (to the next EVEN number).
So, an example of the Menacing Toy Tank's Chassis Control library could look something like:
[4.]126.96.36.1990 (prior release) ---> [4.]188.8.131.520 (functional requirement update) ---> [4.]184.108.40.2061 (Module revision) ---> [4.]220.127.116.112 (testing approved, ready for release)
At Release Time: After the software for the Menacing Toy Tank has been suitably tested as a whole system, the Release number is incremented for the Menacing Toy Tank software package and posted to the release control system.
So, the product's software packge would go from 4.12 to 4.13
Note: This example is predicated on the use of an odd/even-dev/release build numbering scheme.
Note: Although the example demonstrates a 5 number scheme, only the middle three numbers would be necessary for casual use with customers as the released build number can never coincide with any other combination of Major/Minor/Revision and the product code could either be derived via context or displayed with text. Example: "Menacing Toy Tank 1.7.2" would display on the welcome screen while "18.104.22.168.510" would appear in log files and 0004:0107:0002:01FE would appear in a version identification message to another device.