Yesterday I released RPM and DEB packages for the Drizzle 7.1.31-rc Release Candidate. This was the first Drizzle release featuring what I like to call "sane versioning number". Here I will share some background on the Drizzle version number, and what effects that had on RPM and DEB packaging.

Drizzle uses the pandora-build build system created by Monty Taylor. It is essentially a python script on top of autotools, but it also provides the configure.ac and dictates some best autoconf practices upons you1

Now, having an undocumented wrapper script on top of autotools is likely to make things worse, not better. But apart from the lack of documentation, I've found pandora-build being really good. It supports really well Drizzle's refactoring into plugins. Each plugin directory comes with a simple plugin.ini file, which is read by pandora-build and all the autoconf magic is created from there. The developer needn't do anything beyond creating his plugin directory and the plugin.ini file. At least in most cases... some plugins also come with a plugin.ac which is then incorporated to the main configure.ac by pandora-build.

One of the things pandora-build takes care of is putting a version number on your releases. Until now Drizzle used a date-like versioning scheme, such as 2012.01.30. (This was confusing people, because that release wasn't actually released on January 30.) To create a release one simply creates a bzr tag with the release number: bzr tag 2012.01.30.

If you then do "make dist" you get a file drizzle-2012.01.30.tar.gz automatically. Otoh if you do make dist in some branch that wasn't just tagged, Drizzle will create a four part version number for you, where the last part is taken from the bzr revno command. So you would end up with something like drizzle-2012.01.30.2540.

This is a very good feature. First of all it by design ties together the tagging of the bzr repository with the release version. The traditional way of doing this is that the release manager has to edit configure.ac with the release number, and then separately remember to tag the version control repository at the point the release was made. It is of course easy to forget the latter part, and it is difficult to fix after the fact. With pandora-build, such a mistake can't happen.

Also the feature of appending a fourth number for snapshots that were built at non-release points of the codebase is good. This way you can easily see what is a real release and what is something that someone just built out of the sources directly. And it is completely automatic, you don't need to make changes to configure.ac to get the extra number.

To support the new 7.1.31-rc style version numbers, a few changes were needed to the pandora build system.

If you had used this kind of release tag with the original system, things would have worked fine at first. However, what if someone builds a snapshot? You would have ended up with a version like 7.1.31-rc.2550. Not the end of the world, but doesn't look as pretty as I wanted. So a few extra sed commands to strip away the "-rc" tag, and now we get 7.1.31.2550-snapshot style versions instead. Much better.

Note that the -rc and -snapshot tags are purely informational. One could also use just 7.1.31. However, to clear up all the misunderstandings and criticisms we got from the old versioning system, I thought that embedding a tag that tells you whether the release is a -alpha, -beta, -rc or -stable is a good idea. So now you can do that, and it is handled correctly.

A good property of the Drizzle versioning system (both the old and new) is that the version number always increases. Next we will release 7.1.32-rc and then 7.1.33-stable, etc... This way the versions always increase when sorting alphabetically. Quite often you see projects using version strings where 7.1.31-rc1 is a predecessor to 7.1.31-rc2 which is a predecessor to 7.1.31 (the stable version). This is very confusing when sorting alphabetically. Drizzle doesn't have this problem.

Just like MySQL, Drizzle also supports the syntax that some SQL is executed only if your release version is higher than the given string. For instance

SELECT * FROM mytable /*!40101 ORDER BY lastname */;

...would return an ordered result set if your MySQL version is 4.1.1 or higher, but leave it unordered if it was from the 4.0.x series. This string "40101" is in Drizzle known as release_id. You can see it when you do show variables.

The original pandora build would create the release id simply by removing the dots between the version numbers. This worked because a leading zero was used in version numbers as needed: 01 instead of just 1. I wanted to support also single digit version numbers: 7.1.31 instead of 7.01.31. Without changes, that was not possible because Drizzle would then confuse versions 7.1.31 and 7.13.1 as identical.

A little more sed magic and that is now supported too.

The problems began when packaging DEB and RPM binaries. It turns out the dash has special meaning in deb and rpm filenames. In fact, in rpm you simply can't have a dash as part of the version string at all. In debs you can, as long as you also append a "-1", known as the "Debian release version".

Ok, so to make rpm happy, I thought of using a tilde instead: 7.1.31~rc. Unfortunately also this was an "illegal character" for rpm. It seems that the only punctuation allowed in RPM version numbers is the dot and a plus sign (+). Why a plus sign? I have no idea.

On the font I have in my terminal, a version number like 7.1.31+rc simply looked ugly, because the plus character is really big. So I didn't want to use it. Unfortunately we cannot use a dot because at least for deb packages the version 7.1.31.rc would be considered higher than 7.1.31.2550.snapshot, which is incorrect.

The result of this was that our deb packages will use the 7.1.31-rc version as is, but rpm packages are versioned just 7.1.31. This works just fine - again thanks to the fact that the "31" will increase for each release, regardless of whether it is an RC or stable release. But you need to read the drizzle blog to know the release status (alpha, beta, rc, stable) since the information is not embedded in the version string itself.

Once you install the rpm, and connect to the drizzle server, it will print the full 7.1.31-rc version string though.

• 1As if. Autotools best practices of course don't exist...