[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Reply to: [list | sender only]
Re: Cif dictionary version numbers
- Subject: Re: Cif dictionary version numbers
- From: Dale Tronrud <dale@xxxxxxxxxxxxxxxxxx>
- Date: Wed, 20 Jul 2005 13:49:55 -0700
- In-Reply-To: <42DE0902.80604@ccdc.cam.ac.uk>
- References: <42DD21E2.5070908@ccdc.cam.ac.uk> <20050720080002.GA586@emerald.iucr.org><42DE0902.80604@ccdc.cam.ac.uk>
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
Reply to: [list | sender only]
- Follow-Ups:
- Re: Cif dictionary version numbers (Herbert J. Bernstein)
- References:
- Cif dictionary version numbers (Matthew Towler)
- Re: Cif dictionary version numbers (Brian McMahon)
- Re: Cif dictionary version numbers (Matthew Towler)
- Prev by Date: Re: Cif dictionary version numbers
- Next by Date: Re: Cif dictionary version numbers
- Prev by thread: Re: Cif dictionary version numbers
- Next by thread: Re: Cif dictionary version numbers
- Index(es):