Confluence Plugin Development and Confluence Version Compatibility

Introduction

Confluence Plugins can be deployed via the Confluence Plugin Repository. Plugins that are in the repository can have metadata associated with each release stating a startBuild and endBuild for the release. A lot of times, these fields may not be accurate. For example, when 2.6.0 came out, we had no idea that the API would change and that the plugin we wrote would be incompatible with it until we tested it. For this reason, Confluence administrators should make sure that the new Confluence version won't break the plugins they are using before putting it into production!

If you are interested in what versions of Confluence a particular plugin supports, you should look to see whether the plugin shows up in Administration -> Plugin Repository (assuming that you know that plugins will only show up there that are in the repository, support your Confluence build (at least according to the plugin metadata), and aren't filtered out by the rules you have specified about allowing alpha/beta/release-candidate/final release) or the plugin's home page for more information.

Specifying the Confluence startBuild and endBuild in Plugin Metadata

See:

• Packaging and releasing a plugin
• Confluence Plugin Repository

For each release defined in the metadata, there is an optional startBuild and endBuild that can be defined. There may be other options as well. Please check out those pages for the latest information.

Targetting Confluence Build/Version Compatibility

Unfortunately a lot of this comes down to "innocent until proven guilty". Plugin developers will sometimes (often?) not specify the endBuild for a release of their plugin. New Plugin developers might even assume that the plugin works in previous versions of Confluence up to the last major version (like v2.x.x). However, according to veteran plugin developers like David Peterson, even minor releases of Confluence have frequently been incompatible with plugins. The following was originally posted in the confluence-developer mailing list hosted by Atlassian:

David Peterson said:

Personally, the only approach I have found is to simply stop supporting older versions of Confluence once the newest one
stabilises. Keeping up with backwards-compatibility is a nightmare.

(when statement made about a minor build of Confluence breaking plugins due to changes in the API)

I think you'll find that this is a common occurrence. Confluence 2.0 broke the plugins which came for 1.4,
Confluence 2.3 was another major breaking point. In fact, the relative stability between 2.3, 2.4 and 2.5 is pretty rare.
Any future updates, such as 2.7 are unlikely to restore backwards compatibility. They will just add new incompatibilities
of their own. Essentially, we just have to move on with what is now the gold standard...

So it is probably best, unless you really need for a plugin to be compatible with earlier versions of Confluence, to leave the endBuild empty until it breaks with a new version, and then set the release(s)' endBuild property to the last known good Confluence build number. The Confluence build number can typically be found at the bottom of any Confluence page (this can be overridden though) or you can see Confluence Build Information

Incompatibilities/Fixes

This is a very incomplete list. Please edit and add your own!

Confluence API Incompatibilities between Confluence 2.5.7 and 2.6.0

Some notable Confluence API incompatibilities between 2.5.7 and 2.6.0 are:

• ImportExportManager exportAs(...) signature change without deprecating previous method
• log member variable changed from protected/public to private (so starting in 2.6.0 you need to define your own logger member in your action class)
• 2.6.0 was missing the dependency 2.1.1-atlassian-21Mar06 from its Maven 2 pom in the initial public release. Jonathan Nolen fixed this on October 3, 2007. Thanks Jonathan!