Closed bmschoene closed 5 years ago
The first and second number of the version are incremented with each release, if we need to amend the CDS sequence of any allele, we would look to increment the third digit of the version number. Changes to individual file formats may not impact on all files, and so may not necessitate a version number change. For this reason the Git file store is used a way of recording all changes, particularly those that relate to metadata and not sequence changes.
But changes in the annotations and noncoding regions are changes, nonetheless (see those introducd by 4cb4399, which have broken the annotations in several genes, without anyone seeing a version update...). Maybe a 4th field (.V1 etc) might be a good idea.
It would be very helpful if all updates to the database would consistently increase the version number, at least the last digit (add another field, if necessary). There have been substantial changes since the original release of 2.8.0 (especially the latest commit), and these are not visible from the version number. This makes it hard to work with these files.
It would be even better if, additionally, any updates/corrections/renamings of existing alleles would consistently update their last-modified-date in the .dat file and .xml file...
The same goes for HLA, of course.
Would it be possible to implement something like this?