2, 3 or 4 digit iMesh version number

Mark Miller miller86 at llnl.gov
Wed Oct 21 14:13:08 CDT 2009


I kinda agree.

But the alternative is that you are placed in the position of defending
version numbers like 9.3 or 1.27 and/or version number transitions like
from 1.0 to 2.3 instead of 1.0.5 or 1.3.2. My experience is that unless
outside observers really understand whats going on, there is a whole
bunch of baggage that comes in when interpreting those 2 digit numbers.

Nonetheless, I am happy to do as group wants. My recollection is that we
decided upon 3 digits.

Mark


On Wed, 2009-10-21 at 12:25, Tim Tautges wrote:
> I personally think even a 3 digit version number is overkill for iMesh.
> 
> - tim
> 
> Mark Miller wrote:
> > 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!!)



More information about the tstt-interface mailing list