I started working on the teidata.version = teidata.version.unicode | teidata.version.semver | teidata.version.calver | teidata.whatever system today. (In a branch I have not committed, let alone pushed.) Less than halfway through the process I ran into a (moderately embarrassing) problem.

It turns out calVer is not a calendar-based version numbering system as we had assumed during our recent discussions. It is rather a cheerleading document in favor of calendar-based versioning in general, with both a breakdown of the potential components such a version number might use, and a list of specific projects that use a calendar-based version numbering system (along with the pattern of aforementioned components that project uses).

My first reaction is I have no idea what we should do about this. My second reaction is I can easily scope out a range of options, as follows.
  1. Do nothing with calVer — drop it from the list of TEI datatypes-to-be.
  2. Go whole-hog: For every system described by calVer, create a TEI datatype that validates it. E.g., the datatype for the Ubuntu system would be defined with something like
    <dataRef name="token" restriction="([4-9]|[1-9][0-9]|[1-9][0-9][0-9])\.(0[[0-9]|1[0-2])(\.[0-9]+)?"/>
    Datatypes could be named flatly, e.g. teidata.version.ubuntu, or could be named hierarchicly, e.g. teidata.version.calendar.ubuntu.
  3. Something in between. (E.g., calVer divides systems into case studies, notables, and others; maybe do #2 but only for the case study ones.)
I really don’t like #1, because, in general, this is a great way to do version numbering.

I encourage everyone to scan the major portions of the calVer document, if not read the whole thing.