Rapicorn is an experimental graphical user interface toolkit. So it is a project to implement and test out new GUI and programming ideas.

Technically, this means API changes, code refactoring or paradigm shifts needs to be as easy as possible. Because Rapicorn is written in C++, these requirements will result in frequent ABI breaks.

Consequently, the versioning scheme for Rapicorn is designed to not just allow and cope with frequent ABI changes, it even enforces it. Enforcing frequent ABI changes in the versioning scheme protects the programmer from getting locked up for too long in an arbitrary ABI corset and keeps the code base flexible enough for continuous refactoring and interface changes.

Versioning in Rapicorn is implemented as follows:

• A Rapicorn tarball version has a RELEASE part consisting of two numbers and a REVISION part.
• The two numbers that make up the RELEASE version consist of the year and month of the release date. For version comparisons, the two numbers are essentially treated as one number, they are separated only for notational convenience.
• Different RELEASE versions indicate tarballs that are ABI-incompatible with each other. Tarballs with different RELEASE versiosn are parallel installable without affecting each other.
• The RELEASE version numbers increment monthly if certain changes are detected in the Rapicorn header (interface) files.
• The RELEASE version is constructed as: (current_year - 2000) '.' current_month.
• Different even numbered version REVISIONs are ABI-compatible to each other. Versions with a greater REVISION number are meant to replace versions with a smaller REVISION.
• Odd numbered REVISIONs indicate development versions and may exhibit all sorts of brokenness.
• All API changes between two consecutive RELEASE versions have to be thoroughly documented in the NEWS file.