SonarJava 6.6 not available in Sonarqube marketplace

Hi,

according to https://github.com/SonarSource/sonar-java/releases
the new version 6.6.0 has been released 2 days ago.

When will it be available in Sonarqube marketplace ?

Gilbert

Hi Gilbert,

It’s not going to be available in the Marketplace. That’s a first step toward this MMF, which is expected in 8.5:

MMF-2042 - Align languages upgrade strategy on SonarQube lifecycle

 
Ann

Hi Ann,

this is a really eminent change, would be nice to know about those changes before updating.
Even if tracking Sonarsource jira closely i missed that.
How will this affect the mechanism for implementing custom rules that are provided by plugin also ?
Right now my plugin with custom rules works in Sonarqube 8.4.1 as before.

Not sure if i’ll like this decision. I have the feeling of losing some flexibililty.
Let’s say i need Java 14 support coming with Sonar Java 6.6, but i don’t want to update
to the next Sonarqube version that has bundled Sonar Java 6.6

Gilbert

2 Likes

I fully support Gilbert here : this MMF-2042 is going against the flexibility I like with SonarQube.
If my understanding of this MMF is correct plugin : improvements on a specific language plugin will now require a full upgrade of SonarQube ??? I really hope I did not understand correctly so please correct me

JPK

1 Like

@ganncamp, does the referenced MMF imply more frequent SonarQube releases, or will getting access to built-in language updates be slower?

I also imagine blocking bug & vulnerability fixes in language analyzers will still be backported to marketplace plugins for the current LTS (until the next LTS is released)—can you please confirm these points, which aren’t clear on the ticket itself? Thanks!

1 Like

Hi,

good point !
seems there are a lot of questions concerning https://jira.sonarsource.com/browse/MMF-2042
This needs to be clarified and quite some users are eagerly waiting for answers.

These are exciting times and time slots for testing and upgrading tools during the remaining year are getting smaller - thus we need all details.

e.g. will you do a new Sonarqube release after every problem with a language scanner ?! , think of

after switching to Eclipse compiler frontend with Sonar Java 6.0.1

Gilbert

Hi all,

I’m sorry it’s taken so long to come back to this topic. We haven’t been ignoring it. Chris, the SonarQube Product Manager, made an official announcement today:

I do want to respond here to a couple points he doesn’t address directly:

Your ability to implement/maintain custom rules should be unchanged. I believe we’re still exploring how best to communicate changes in the underlying analyzers from SQ version to version (we certainly don’t want to dump all the tickets into a single Jira repo!). But you should still have access to the same level of information about API changes.

One of the things this policy shift does is allow us to evolve a little more swiftly, so it’s possible that there could be some API changes that affect you, but I currently don’t anticipate much there.

I understand. There are certainly trade-offs. We do believe that in the end this makes the most sense for everyone involved.

You’ll need to do the SQ upgrade to get the language changes. :woman_shrugging:

We have no current plans to increase the SonarQube release cadence.

Actually, I believe the plan is to do bug-fix releases of the LTS itself. And for your example @Rebse, it would be a bug-fix version of latest.

 
HTH,
Ann

3 Likes

To extend Ann’s excellent post — for the 7.9 LTS such releases should still come through the marketplace (as has already been the case for 6.3.1 and 6.3.2 of our Java analyzer).

1 Like

Hey Gilbert, I’m one of the developer of the Java Analyzer, part of the SonarSource Languages Team, and I just want to let you know that we really understand the situation you are facing here. This new release process impacts all the analyzers at SonarSource and we, as the team developing them, have to face the same questions internally, especially as we were quite used to independent plugins life cycles.

Now, I can only commit on the fact that we will back-port any blocking issue or reported vulnerability to the LTS versions of the plugins. We now consider as frozen the version of the plugins available with SQ 7.9.x. Regarding FPs, FNs, updated or newly developed rules, there will be no back-port.

  • For the Java analyzer particularly, and to take it as an example, we are consequently going to continue the 6.3.x branch, which is now our analyzer simili-“LTS” (this version fixed the issue we were facing with performance). These bugfixed versions will always be available through the marketplace.

  • Like @ganncamp mentioned, in order to benefit from latest features (Java 14 support, new rules, FPs/FNs fixed, etc.), you will indeed need to rely on the SonarQube 8.X series, which is from now on the only way to get new versions of analyzers on SonarQube. Here we benefit to stop having to rely on old SQ API, and only builb on top of the ones from SQ 8.X series.

  • Regarding evolution of the Java API for custom rule plugins, I assure you that we will make our best to not drop anything before the next SonarQube LTS is released. However, the new lifecycle of the Java language itself (Java 15 being released at the end of this month) forces us to adapt a bit on some particular items (namely: preview features disappear or evolves from one version of Java to another, and they have consequences on the shape of the AST). Also, feel free to ask any question you might have in the appropriate forum (#plugins or #plugins:customrules), and we will jump in to give a hand.

Cheers,
Michael

2 Likes

Hi @ganncamp , @Chris and @Michael

thanks for clarification !
So it seems both sides are in a similar situation, let’s see how it goes / get used to it…

Gilbert

1 Like