[Dovecot] 1.0.rc24 released

[Richard Laager]

On Thu, 2007-02-22 at 20:48 +0200, Timo Sirainen wrote:
> 	* Dovecot now fails to load plugins that were compiled for different
> 	  Dovecot version, unless version_ignore=yes is set. This needs to be
> 	  explicitly set in plugins, so out-of-tree plugins won't have this
> 	  check by default.

Here's what is done in Gaim, which I think is really useful:

Each plugin has two fields, major and minor. Generally, a plugin will
have major set to GAIM_MAJOR_VERSION (thus meaning the plugin binary
will store the major version of the version of Gaim it was compiled
against). The minor version is generally set to zero, but I'll get to
that in a second.

When Gaim probes plugins, it only loads plugins if the major version in
the plugin equals the major version in Gaim. Thus, if we break backwards
compatibility in the API, we bump the major version number. (For
example, we're working on version 2.0.0 right now.)

The minor version is used for API additions. So, if we add a new
function call, for example, that doesn't break backwards compatibility.
Thus, we wouldn't increment the major version. Instead, we increment the
minor version. So now, if a plugin needs that feature, it can specify
the required minor version in its plugin structure.

So, for example... For a Gaim plugin I wrote, I wanted to make it
possible to indicate when a plugin preference was storing a password, so
the UI would mask it (with bullets). I wrote a patch to Gaim and sent it
in. (I wasn't a developer with commit access at the time.) The
developers committed it and the next release had the minor version
bumped, making it 1.2.0. Then my plugin had the following code for those
two fields:

GAIM_MAJOR_VERSION, /* major */
2, /* minor */

This way, the plugin would only load if you had Gaim >= 1.X where X was
2 or higher.

(In reality, I actually had some #ifdefs to allow you to compile against
Gaim 1.0.* or 1.1.* and just not get the new feature.)

This versioning scheme forces the application numbers to match the API
(basically just like library version numbers), but it makes plugin
versioning a snap. You can add all the functionality you want, as long
as it doesn't break compatibility, and existing plugins keep working.

Richard

P.S. Please no flames (on this list -- private e-mail or gaim-devel
only) about Gaim, the lack of a final release of 2.0.0, etc.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://dovecot.org/pipermail/dovecot/attachments/20070222/f5d2d138/attachment.pgp