Re: Cif dictionary version numbers

["Herbert J. Bernstein" <yaya@xxxxxxxxxxxxxxxxxxxxxxx>]

In the world of software, versions can be rather arbitrary
strings, as in RasMol 2.6ab2.  However, I personally think life
is simpler if we structure the string, much as we structure a date
string, in a hierarchy, in this case with the top of the hierarchy
first, i.e. the major version, and work our way down.  For RasMol,
I have taken it as far as 5 levels, e.g., the very popular
RasMol 2.7.2.1.1.  For our dictionaries, three levels is
probably sufficient.  I don't think people have too much trouble
sorting dates, even when we do foolish thing such as mixing
keywords and numbers and using a funny ordering (e.g. mmm-dd-yyyy),
so I suspect that most people will be able to cope with the
relative ordering of, say, 3, 3.5, 3.5.7, 3.6, and 3.15.38.
I agree that it would be nice to have a tags for release status
with values such as alpha, beta and stable, but I am not sure
that is really a version tag.

Therefore, I would suggest that the tag _dictionary_version be
regressed from numb to char, with semantics specifying periods
as separators between components, with numeric components, and
hierarchical sort ordering.  This would correct both the
failure to allow a third level of versioning, and the problem
Dale points out of incorrect sort order between version 1.2
and 1.12



At 1:49 PM -0700 7/20/05, Dale Tronrud wrote:
>    I am sorry for leaving my "fly on the wall" status, but it seems to
>me that this version numbering problem is more basic.  As soon as Dr. Towler
>mentioned parsing the version number it seemed clear to me that the problem
>is that multiple pieces of data are being packed into a single data item.
>
>    The version identifier cannot be a number.  Certainly version 1.1 differs
>from 1.10.  Does it make sense to say that version 1.2 is greater than 1.12
>when we expect that 1.12 is a much more recent version?  The dot in 
>the version
>number is not a decimal point, but simply a separator.  One could just as
>well write version identifiers as 1/1, 1-1, or 1!1 and have the same meaning.
>
>    This would probably break just about everything, but if you insist that
>there is meaning to individual parts of the version identifier, I think you
>need to have _dictionary_version, _dictionary_subversion, and
>_dictionary_subsubversion data items.  This would eliminate any 
>parsing issues,
>and have unambiguous ordering rules.
>
>    If you want beta versions, I think you would need yet another 
>data item that
>could assume the values of "alpha", "beta", "gamma", and "final".
>
>    And now, I'm flying back up on the wall...
>
>Dale
>
>Matthew Towler wrote:
>>I agree that three level numbering is useful
>>
>>>So I would favour leaving the version labelling as now, but changing the
>>>type of _dictionary_version in any new DDL1 release that results from this
>>>and other of the recent bug reports.
>>
>>
>>The only problem with this is that it completely rules out any 
>>future parsing of version numbers.  Reading three numbers would be 
>>plausible, but not once free form text such as 'beta' starts being 
>>added; and once it is a free form text field there is no telling 
>>what form of words will be used.
>>The alternative I would prefer would be simply to drop the second point e.g.
>>
>>1.0.1 -> 1.01
>>2.3.1 -> 2.31
>>
>>This still means we get three level numbering, but can also treat 
>>the values as numbers.  The only restriction is that we can only 
>>have nine minor (0.1) revisions.
>>I think that text such as 'beta' can and should be included in the 
>>_dictionary_name.  There it is more likely to be obvious to users 
>>than in the version field.
>>
>>Matt
>>
>>_______________________________________________
>>cif-developers mailing list
>>cif-developers@iucr.org
>>http://scripts.iucr.org/mailman/listinfo/cif-developers
>_______________________________________________
>cif-developers mailing list
>cif-developers@iucr.org
>http://scripts.iucr.org/mailman/listinfo/cif-developers

-- 
=====================================================
  Herbert J. Bernstein, Professor of Computer Science
    Dowling College, Kramer Science Center, KSC 121
         Idle Hour Blvd, Oakdale, NY, 11769

               Office:  +1-631-244-3035
            Lab (KSC 020): +1-631-244-3451
                  yaya@dowling.edu
=====================================================
_______________________________________________
cif-developers mailing list
cif-developers@iucr.org
http://scripts.iucr.org/mailman/listinfo/cif-developers