Hi all,
I’m not stoked today. AtlasCamp is finished, and I am still kind of hurting after the festivities. Today I’m going to blog about something far more mundane, but very urgent and important to anybody who has plugins listed on the Plugin Exchange: compatibility data.
Since we released the Universal Plugin Manager in June, it’s had nearly 4,000 downloads from the Plugin Exchange. Just a couple days ago, during AtlasCamp, Confluence 3.4 became the first Atlassian product to bundle the UPM. Upcoming releases of Jira, Fisheye and Crucible are expected to bundle the UPM as well, so we’re expecting it will be seeing pretty heavy use in the coming months.
What does this have to do with compatibility data and the Plugin Exchange, and why the urgency?
A big part of the UPM’s job is to make it easy for admins to keep both their Atlassian products and their installed plugins up-to-date. The latest Confluence docs have a great example of the information that the UPM presents to administrators. Our experience over past releases is that some administrators won’t update to the latest version of a product until the plugins they use in that product are listed as compatible, and likewise, other administrators will uninstall incompatible plugins in order to upgrade. Since this compatibility information — which is pulled into UPM via the Plugin Exchange’s REST API — is much more visible now, we expect there will be more administrators sending email both to Atlassian and to many plugin vendors asking “hey, why can’t I upgrade” or “why aren’t any plugins compatible with the new Confluence release?”
We want to avoid this situation as much as possible, so we’ve recently taken a couple baby steps towards our long-term goal of having most plugins (both on the Plugin Exchange and elsewhere) compatible with new Atlassian product versions before the products are released:
- First off, we’ve started publishing API change documentation for new product releases. These are auto-generated using clirr, but there are still many manual aspects to the process. Specifically, Ben has to know that a new production or EAP release is available, run clirr (which is easier for some of our products than others, depending on their build processes) and manually upload the report to Confluence. We’re hoping to automate as much of this as possible, as well as improve the quality and relevance of the reports (for example, highlighting the APIs that we know are used most frequently).
- Additionally, we’re working on an opt-in notification mechanism (tied in with the Early Access Program, and likely managed through my.atlassian.com) to alert plugin developers that new product releases are available for testing. We don’t have much info to provide on this project yet, but we’re hoping to have something ready for use as soon as possible.
- Finally, since this automatic notifier isn’t available yet, we’ve decided to spam notify plugin developers of important product releases by hand. I sent email to a couple hundred Confluence plugin developers today (and actually, I’ll admit I did get a little bit stoked in the process), and I expect that when the rest of our UPM-enabled products are released, I’ll send out a similar notification again.
The goal, at the end of the day, is to make sure as many plugins are compatible with our newest product releases as possible. So if you’re a plugin developer, particularly a developer who has plugins listed on the Plugin Exchange, please take a moment to test your plugins against the latest versions of their respective products and make sure the compatibility data in the Plugin Exchange is correct. This will encourage users and administrators to keep up-to-date both with your plugins and with our products, all with a single click in the UPM.
As always, please feel free to ask questions about this on our Developer Forums, or email us directly at developer-relations@atlassian.com.