Drizzle versions and RPM deficiencies

hingo's picture

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.

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

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Henrik Ingo: Drizzle versions and RPM deficiencies | Weez.co's picture

Pingback

[...] read more [...]

Sean's picture

tilde in RPM

recent version of RPM do support the tilde, but it isn't the recommended way to do things.

From: http://fedoraproject.org/wiki/Packaging%3aNamingGuidelines#NonNumericRel...

Non-use of tilde "~"
rpm-4.10 and above support the Debian-style tilde character which causes a piece of the version to sort before anything else. At the moment, using this is not permitted for these reasons:
it is not necessary when the following release tag guidelines are followed properly.
it is not supported by rpm in currently supported Fedora releases.
it introduces another special character to achieve something which can be handled in other ways.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Post new comment

The content of this field is kept private and will not be shown publicly.
  • Use [fn]...[/fn] (or <fn>...</fn>) to insert automatically numbered footnotes.
  • Allowed HTML tags: <h1> <h2> <h3> <h4> <p> <a> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd> <br> <sup> <div> <blockquote> <pre> <img>
  • Lines and paragraphs break automatically.
  • Web page addresses and e-mail addresses turn into links automatically. (Better URL filter.)

CAPTCHA
This question is for testing whether you are a human visitor and to prevent automated spam submissions.
7 + 10 =
Solve this simple math problem and enter the result. E.g. for 1+3, enter 4.