About Release Engineering

Historically, Cat's Eye Technologies has usually identified each release of a software project with only a release number. The release number is really just the date that the software was released, formatted as YYYY.MMDD. Each of Y, M, and D is a single digit, so that it sorts nicely, even in a purely lexicographical sort order. In retrospect, 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 projects like ours, which rarely have any maintenance needs warranting branches and such. But most of our projects do implement 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 projects used a different convention, usually two numbers 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 meaningless) letter.

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 project now carries both a version and a revision. The version consists of a major version number and a minor version number, in the format A.B, where A and 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 project has the same interface (syntax and semantics, API, protocol, or what have you depending on what kind of project it is) as the previous release of that project, then the version will be the same as the old project, but the revision will be different.
• If a new release of a project 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 project 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.