Discussion List Archives

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Cif dictionary version numbers

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

Reply to: [list | sender only]
International Union of Crystallography

Scientific Union Member of the International Science Council (admitted 1947). Member of CODATA, the ISC Committee on Data. Partner with UNESCO, the United Nations Educational, Scientific and Cultural Organization in the International Year of Crystallography 2014.

International Science Council Scientific Freedom Policy

The IUCr observes the basic policy of non-discrimination and affirms the right and freedom of scientists to associate in international scientific activity without regard to such factors as ethnic origin, religion, citizenship, language, political stance, gender, sex or age, in accordance with the Statutes of the International Council for Science.

Useful links