2, 3 or 4 digit iMesh version number

[Mark Miller]

Hi All,

Last week we talked about the fact that, technically speaking, we should
only ever need a 2 digit version number for iMesh because it is really
just an interface specification. Other than the header file itself,
there is no real code to version. However, we agreed that a 3rd, patch
digit which ordinarily applies only to bug fix releases of code
underpinning an interface, gives us finer control over the version
number and has value just for that reason.

I'd like to raise the possibility of a 4th digit.

In Silo and HDF5, a 4th digit is used solely for the release process
itself. Typically, the release process does NOT got smoothly the first
time out. So, we acknowledge that by creating 'release candidates' and
tagging them such as Silo-4.7.1-pre1. If during the release process
(testing on various platforms) bugs are found. Those bugs are
immediately fixed and a new release candidate is created called
4.7.1-pre2. This process iterates until everything is stable everywhere.
Then, the 'preX' nomenclature is removed, the release candidate becomes
the release and the final 4.7.1 release is made.

I know of at least one or two points in our recent ITAPS history where
we've experienced a similar sequence of events with the iMesh.h header
file causing it to have to be immediately modified and everyone updating
to that version.

Now, we could just opt to use the 3rd digit for this process. That may
result in that digit changing more frequently than 'users' would expect
but would otherwise I think be fine.

I just wanted to get others input on this as I am in middle of modifying
iMesh.h with version stuff we agreed to last week.

Mark

-- 
Mark C. Miller, Lawrence Livermore National Laboratory
email: mailto:miller86 at llnl.gov
(M/T/W) (925)-423-5901 (!!LLNL BUSINESS ONLY!!)
(Th/F)  (530)-753-8511 (!!LLNL BUSINESS ONLY!!)