|The stupid question is the question not asked|
Re: Versioning modules in a packageby BrowserUk (Pope)
|on Oct 04, 2004 at 19:13 UTC||Need Help??|
Long, long ago, in days of yore, I was brought up using 3-level version numbers: XX.YY.ZZ
Increments at any level are only made once unit/system and regressions test suite have been run and passed.
Occasionally, if large numbers of bug fixes or enhancements meant that midor or minor were approaching 3 digits, then a "maintainance increment" of the next higher level was made to avoid that.
So far, I not seen a better system.
The upshot is, the version of your subpackages should live their own lives and be pretty much unrelated to the versioning of the parent.
However, a change in the major (XX) version number of a subpackage should result in an increment in the the midor (YY) of the parent.
If both subpackages modify their external interfaces, then both their major version increment, and the midor of the parent is incremented twice.
(Though if you want to avoid major woes, you modify one subpackage at a time, and then the dual increment of the parent becomes obvious.)
Update: The reason why I consider this a good system is because any code that uses (only) the published interface, will be compatible whilst the Major version number remains the same.
This is especially useful with dynamically link libraries as newer, but major version compatible .dll/.so files can be substituted for earlier ones without rebuilding the calling code.