Skip to end of metadata
Go to start of metadata

Table of Contents

If you have developed a SonarQube plugin, please let us know so that we at least reference it!

And if it meets the requirements, we can even add it in the SonarQube Marketplace.

Requirements

If your plugin meets the following requirements, then you can ask SonarSource (on the SonarQube Google Group) to reference your plugin in the SonarQube Marketplace:

  1. Your plugin is open-source
    1. Source is freely accessible
    2. The license is a known FLOSS one (check the list provided by the Open Source Initiative)
    3. There's a public issue tracking system
    4. Documentation is available online in English
    5. Binaries of each version are accessible somewhere
  2. Releases follow open source conventions
    1. For each release the following must be available:
      1. release notes that reflect all significant changes in the version
      2. plugin jar
  3. The key of your plugin should be:
    1. short and unique
    2. lowercase (no camelcase)
    3. composed only of [a-z0-9]
    4. related to the name of your plugin
    5. examples: motionchart, php, scmactivity
  4. The description of your plugin must not be misleading in terms of content (the code needs to do pretty much what the name and description say it does). 
  5. On initial entry into the Marketplace, SonarSource staff will test the plugin to verify reasonable functionality and quality. SonarSource staff must be provided with the necessary means to do this testing without the need to sign any agreements or fill out any forms. Ideally, the means to do this testing will be made available to the community at large, with the same lack of restrictions.
  6. Your plugin does not compete with existing SonarSource products (sorry, but we gotta pay the bills somehow)
  7. It is analysed on SonarCloud and the quality gate is green when doing a release
  8. It is compatible with the platform requirements (e.g. it runs on the minimum listed JRE)
  9. Last but not least: your plugin must be aligned with the goal of the SonarQube platform: management of the technical debt and the quality of the code
    1. To be more precise: every feature of SonarQube is tied to the code, so if your plugin provides data that can't be attached to a source or a test file, then there are chances that your plugin won't be accepted in the Marketplace

If your plugin meets these requirements, feel free to start a new thread on the SonarQube Google Group requesting inclusion. This thread should include plugin:

  • description
  • home page url

as well as the elements of a "new release" email listed below.

We reserve the right to exclude from the Marketplace plugins that we feel would be a dis-service to the community.

Announcing new releases

When you've got a new release that should be published in the Marketplace, please start a new SonarQube Google Group thread with the following information:

  • Subject: [NEW RELEASE] Plugin Name & version
  • Body contains:
    • Short description: a few words about what's new in this version.
    • Sonarqube compatibility: unchanged or specific versions.
    • Download URL for the plugin binary
    • Link to release notes
    • Link to SonarCloud project dashboard so that we can check the quality gate status
  • If it is the first release of the plugin, please mention that the plugin should be added to the Plugin Library page

Once this email is sent, someone from SonarSource will perform the manual steps to make the version available in the Marketplace.

Suggestions to manage your plugin development

A project hosted in a GitHub repository can easily meet the requirements:

  • Sources are on Git - and you can easily configure them to be built by Travis CI
  • GitHub Issues can be used as a bug tracking system
  • GitHub Wiki can be used to write the documentation
  • GitHub Releases can be used to publish your binaries

You can obviously use the SonarQube Google Group to ask for feedback on your plugin. You may want to post an RFF (Request for Feedback) before a release although it is not required. If you do, please close the thread before final release with a "feedback period closed" notice.

Deprecation

Occasionally, there's a need to deprecate a plugin. Typically for one or more of the following reasons:

  • the functionality is obsolete or relies on deprecated platform functionality.
  • It's no longer maintained by its authors and is buggy.
  • It's no longer compatible with supported versions of the SonarQube platform.

In such case, the plugin is removed from the Marketplace.

F.A.Q.

Q. What should the release candidate announcement look like?
This is up to you, but ideally, it will contain a:
  • link to download the RC, 
  • link to the version change log. 
  • deadline for feedback
Also, you should probably mention the contributors to the version if you didn't handle it solo.

Q. How long should the feedback period be?
Again, that's up to you; it's your plugin. At SonarSource, we use a minimum 72 hour feedback period (with variations for holidays, weekends, and significant feedback).

Q. Who can give feedback?
Anyone! In fact, the more feedback the better. That's what makes developing in a community so wonderful. We just ask that when you have feedback, you keep it polite and respectful.

Q. What if I don't get any feedback on my release candidate?
You have two choices: agitate for more attention or consider no news to be good news and proceed with your release.

Q. What if I get feedback that should block the release?
The normal course of action here is to address the feedback and put out another release candidate. Typically, you would extend the feedback period to give people time to test the new version.

Q. What happens when the feedback period is over?
If you didn't get any feedback that you feel should block the release, then send a "period closed" notification on the same thread, perform the release, and in a separate thread ask that the new version be added to the Marketplace.

Q. Should the initial release of a plugin be handled any differently than subsequent releases?
Not necessarily, although it's probably more critical to get feedback on an initial release. So if there's no response within the initial feedback period, you should probably agitate for more attention, instead of assuming that no news is good news. It's up to you, though.

Q. Who performs the release process?
You do.

Q. Where should the jars be posted for download?
Up to you. If you're using GitHub to host your source code, then the easiest thing to do is create a project release and post downloads there.

Q. What should the release notes look like?
In the best case, it will be a publicly accessible list of work tickets handled in the version, similar to what you can get from Jira or GitHub Issues. At minimum, it will be an outline of the work done. In either case, it must reflect all significant changes.
  • No labels