Historically, Cat's Eye Technologies has usually identified each release
of a software distribution with only a release number. The release number is
really just the date that the software was released, formatted as
YYYY.MMDD. Each of
D is a single digit, so that it
sorts nicely, even in a purely lexicographical sort order. In
YYYY.MM.DD might have been a more structurally consistent
choice, but it's not as nicely symmetrical.
Using only the release date to identify releases mostly suffices for distributions like ours, which rarely have any maintenance needs warranting branches and such. But most of our distributions do contain implementations of programming languages, and these languages may or may not change between releases. For example, if we're just fixing bugs in a feature of the implementation, or clarifying the documentation or whatever, that's not a change to the language. But if all we use to identify it is a release number, you can't tell if it's a change to the language or not.
In addition, some of our distributions used a different convention, usually
A.B which resembled a fraction in decimal notation: often
B would be two digits (like 94) which did not count the number of
minor releases since the last major release cycle, but rather tried to
measure "how close" it was to the next major release cycle. Version
numbers like this were sometimes also followed by an (essentially
Realizing what a mess this is, we have strived to revise our release identification system, as well as to make it more consistent.
With few exceptions, every distribution now carries both a version and a
revision. The version consists of a major version number and a minor
version number, in the format
B are both
non-negative integers. The revision is the same as the old release
number, that is, it is the date in
YYYY.MMDD format. The version and
revision are separated by hyphens, so a new-style "distfile" name
typically looks like
foo-1.3-2009.0116.zip (although we are by and
large still providing only the legacy distfiles for download).
The rules for when these numbers change are as follows:
- If a new release of a distribution supports the same interface (syntax and semantics, API, protocol, or what have you) as the previous release of that distribution, then the version will be the same as the old distribution, but the revision will be different.
- If a new release of a distribution is more-or-less backwards-compatible with the previous release, then the major version will be the same, but the minor version and revision will be different.
- If a new release of a distribution is distinctly not backwards-compatible with the previous release, then the major version will be different, the minor version is typically reset to zero, and the revision will of course be the date of the release.