Uploaded image for project: 'Product Roadmaps'
  1. Product Roadmaps
  2. MMF-2042

Align languages upgrade strategy on SonarQube lifecycle



    • Type: MMF
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Labels:



      SonarQube is a product which provides different features depending on the edition you run, not plugins. Every SonarQube release provides new features, improvements and fixes for the different languages. Still, currently, built-in languages are technically installed as plugins and are displayed in the marketplace. Users can upgrade languages to benefit from the new features a couple of weeks before the new version of SonarQube is available.

      It sustains an ambiguity regarding the fact that languages are really features delivered as part of a SonarQube version. It also makes the upgrade of the product complex, specifically in the Docker world.

      We decided to remove the ability to upgrade languages in SonarQube. The product should now reflect this change and adjust the way we present languages.
      With this change, we expect the upgrade process be become much more easy.



      As a SonarQube administrator

      I should not see languages presented plugins:

      • I should not see built-in languages among all the plugins I can install, remove, update from the Marketplace.
      • I should not see references to plugins for built-in languages in the interface.

        This quality profile is provided by a plugin.
        It will automatically be updated when a new version of the supplying plugin changes its definition

      • I should not see versions of languages - ie. I have SonarQube 8.4 Java features not the version 6.5 of the Java analyzer.
        • I should not see new versions of languages I don't have access to.
        • Also, in the documentation including the Plugin Version Matrix, I should not see new versions of language.


      • I should be able to know easily the languages I benefit from.
      • I should be able to find details about the changes a new SonarQube version brings on languages.
      • I should be able to find where related issues are tracked.
      • And I should be able to deactivate a language (see MMF-1223)

      As an Ops upgrading the product

      • I should not have to handle languages as plugins, and to take care not to copy language plugins while copying non-default plugins. This applies whatever the way I run SonarQube, from the zip file or the Docker image.
      • The same should apply to the Git and SVN plugins which are built-in features but are still installed as plugins.

      As a developer

      • I don't really expect languages to be presented as different analyzers (see the About page).


      • Some users remove a language plugin to keep only the languages they are interested in => If we don't provide a new solution for this, the current workaround should keep working.
      • The marketplace is showing the evolution of languages. The solution we'll provide should give visibility over language features we deliver for each version as well as over the open issues.



      • Since language analyzers are no longer plugins, we will remove them from the marketplace. We will also remove SVN and Git plugin from the marketplace.
      • We will also remove them from the extensions/plugins folder, and place them in the "lib" folder.
      • We'll update the upgrade documentation so that languages are no more handled as plugins.
      • We will remove mentions of upgrading analyzers or versions of analyzers from SonarQube, as well as from the documentation to avoid any possible confusion.


      • We'll keep issue tracking links in languages online documentation.
      • For each release, we'll create SonarQube tickets that will describe the new features added for each language, with a link to the languages release notes of to see more details about it.



      • Remove any mentions of the languages plugins in SQ documentation
      • Update the upgrade procedure in SQ documentation, including for Docker

      Release Process

      Includes updating the functional release process:

      • Document a process of the way we manage languages updates and document release notes.
      • Stop marking plugins as compatible with the new versions of SQ.


      • Move and handle (uninstall, load) SonarSource plugins from `lib/extensions` directory, make sure they are loaded first while treating them internally as plugins
        • If duplicate are detected with some older version installed, startup should fail with a clear message.
      • Filter SonarSource plugins from marketplace WSs
        • Classify internal plugins as bundled during load, extend plugins table with plugin type
      • Nice-to-have: Pull GIT, SVN plugins to SQ repository

      API changes:

      Add new internal param named 'type' to WS api/plugins/installed endpoint, which will allow to filter plugins by its type (bundled/external)


      • plugins/installed - filter bundled plugins
      • plugins/uninstall - disable possibility to uninstall bundled plugins using language key


      • Remove any reference to plugin/analyzer from our web application
        • About & quality-profile pages have been identified so far
      • Marketplace should call api/plugins/installed?type=EXTERNAL.
      • Documentation should call api/plugins/installed?type=BUNDLED.
      • Remove the version history of a language plugin from its documentation page
        • Stop supporting the old html comment tag => will stop displaying the version's history component in the languages pages, but also in the scanner pages (we don’t want that, see next point)
        • Support the new react tag in the static documentation so that the version's history component is still able to work on scanners pages (see https://using-remark.gatsbyjs.org/custom-components/).
      • Inject the issue tracker url before the documentation page. (This is a branch we can cut if needed)
        This information is available:
        • Embedded doc: from api/plugins/installed?type=BUNDLED
        • Static doc: into the manifest.mf file.
          • This file should be extracted from the zip the same way it is done for the documentation.md file. Both files should be extracted in a plugin dedicated folder so we can link a manifest to its md file.
          • The parser should read the manifest and link the issue tracker url to the key found in the md file.


          Issue Links



              christophe.levis Christophe Levis
              christophe.levis Christophe Levis
              0 Vote for this issue
              10 Start watching this issue