[ANN] SonarQube 6.5 RC1 is now available

[Fabrice Bellingard]

Hi SonarQube Community,

Here is the first public release candidate of SonarQube 6.5.

The main features and noteworthy of this 6.5 version are:

• Better understand the history of a project
  
• The Activity page gets (several predefined and one customisable) charts to display the evolution of a project, with the ability to zoom in and out to clearly spot analyses that triggered some anomalies
• These timeline charts are quickly and easily accessible from the project home page, which displays a small chart to give a quick overview (on top of the background timelines already available)

• "Leak" perspective on the Projects page
• On top of all the visualisations introduced in 6.4, the Projects page now offers the ability to concentrate on the leak information of your projects

• Built-in quality profiles
• To make sure that no one misses new valuable rules, quality profiles provided by plugins are now read-only and automatically updated on plugin upgrade
• On custom quality profiles, SonarQube displays a small message to notify you when "Sonar way" rules are missing in your quality profile

• Onboarding tutorial for new users
• If you download and install SonarQube for the first time, a tutorial will be displayed the first time you log in to help you get started as fast as possible
• Existing users can still find this tutorial in the "Help" of SonarQube

And obviously as usual, this version comes with lots of bug fixes and other small improvements.


To help us test this new version, here's all what you need to know:

• Download: https://sonarsource.bintray.com/Distribution/sonarqube/sonarqube-6.5-RC1.zip
  
• Release notes: https://jira.sonarsource.com/jira/secure/ReleaseNote.jspa?projectId=10930&version=13805 
  
• Staging Documentation: http://docs.sonarqube.org/display/SONARNEXT/Documentation
  
• Upgrade notes: http://docs.sonarqube.org/display/SONARNEXT/Release+6.5+Upgrade+Notes 

Any feedback is highly appreciated.
Enjoy!

Best regards,

Fabrice Bellingard | SonarSource SonarQube & SonarCloud Product Manager http://sonarsource.com

[seet...@gmail.com]

Hoping to see all open JIRA issues being resolved.

[Simon Brandhof]

Me too, I'd love that. Unfortunately only the tickets of 6.5 are closed. There are still many open tickets to be addressed in future releases :-)

--
You received this message because you are subscribed to the Google Groups "SonarQube" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sonarqube+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sonarqube/ba187d6b-4808-4162-8825-f60d3b6e2340%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Simon Brandhof | SonarSource

Co-Founder & Tech Lead

@SimonBrandhof

http://sonarsource.com

[seet...@gmail.com]

It seems like there are a lot of open issues in Java that Sonar may have not envisaged as of now and maybe the coding style was different then.

Also sonar scans for private methods only and does not consider other methods defined in other specifiers

[Julien Lancelot]

Hi Seeteshh,

Please open a new thread and describe exactly what are you talking about : 

• Change of behavior of SonarQube / Plugins from previous version ?
  
• Bugs found in SonarQube / Plugins ?
• False positive ?

Thanks.

Regards,

Julien Lancelot

To view this discussion on the web visit https://groups.google.com/d/msgid/sonarqube/52117f4c-9a4b-4c20-9492-f905f55fd538%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Julien Lancelot | SonarSource

http://sonarsource.com

[Günter Wirth]

Hi,

Thanks for providing the first RC of SQ 6.5. Had a first short look to it on https://next.sonarqube.com/sonarqube/about.

Some first comments:

• ·         missing documentation metrics
• ·         missing a hotspot page
• ·         missing customizable dashboards
• ·         missing the good old technical debt in $
• ·         in general: prefer heatmaps against this bubble charts
• ·         measures:
• ·         some subpages have treemaps (e.g. All Measures / Coverage Measures) some not
• ·         Would anyway call it heatmaps?
• ·         Activity
• ·         Activity / Overview: should be technical debt?
• ·         Activity / Custom: hard to read because all characteristic curves are somehow blue

Regards,

[G. Ann Campbell]

Hi Guenter,

I'm disappointed by this response because I find it unconstructive. This version doesn't purport to reintroduce documentation metrics (which you've already raised an gotten an answer on in a separate thread) , a hotspots page (another topic on which you started a dedicated thread), customizable dashboards (on which there have been many threads), or technical debt in $ (wha? this ship sailed a long, long time ago). If you want to continue lobbying for these things, that's your right, but I don't think this thread was the place to do it.

On Wednesday, 19 July 2017 12:24:07 UTC-4, Günter Wirth wrote:

• ·         in general: prefer heatmaps against this bubble charts

Could you explain why? Is this a question of personal taste, or do you really see a difference in usability? 

• ·         measures:
• ·         some subpages have treemaps (e.g. All Measures / Coverage Measures) some not

You're right, and it may not be immediately obvious why, but the pattern is that Treemaps are offered only for Metrics on which there's a fixed scale, so: percentages and ratings. As an example, if we tried to draw a treemap for the number of Code Smells I guess it's easy to say that 0 issues would be green, but how many code smells should it take to get to red? Whatever the number, if you add one more, then the scale shifts, and what was yellow yesterday becomes green(ish) today.

 

• ·         Would anyway call it heatmaps?

Sorry, I don't understand what you mean here. 

• ·         Activity
• ·         Activity / Overview: should be technical debt?

In fact, the scale here is not coder-hours but plain issue count. "Overview" may not be the best name, but Technical Debt surely doesn't fit. It's possible that this chart will evolve, but nothing has been finalized.

 

• ·         Activity / Custom: hard to read because all characteristic curves are somehow blue

This is a great point, and we're already planning to address it: SONAR-9543.

 

Ann

[Günter Wirth]

Hi Ann,

 

Feedback is a gift – just accept it. And I think you also have to see it positive: as long you get feedback there is still interest in your product.

 

The thing I’m disappointed is that starting with SQ 5.6 every new version focuses mainly on internal clean-up and removing features. From new versions I would normally expect more customer value and not less. And looking to the forums it seems that I’m not the only one with this opinion.

 

 … or technical debt in $ (wha? this ship sailed a long, long time ago).

 

SQ was starting with the proposal to be a tool to measure Technical Debt. I like to quote Dave Smith: “Technical Debt is a wonderful metaphor developed by Ward Cunningham to help us think about this problem. In this metaphor, doing things the quick and dirty way sets us up with a technical debt, which is similar to a financial debt.” The problem is that the executives understands only $. So removing the total cost and replace it with home-made metrics (like A-E …) removes a lot of benefit (at least for the executives).

 

… and yes I remember the good old times where you had an overview picture with total technical debt in $ and a percentage distribution into different areas like issues, coverage, duplicates, … .

 

 … in general: prefer heatmaps against this bubble charts

 

For me heatmaps are much easier to read. It gives a better overview of all components/files, their size and their current state. With bubble charts I typically have the problem of overlapping circles.

 

… As an example, if we tried to draw a treemap for the number of Code Smells I guess it's easy to say that 0 issues would be green, but how many code smells should it take to get to red? Whatever the number, if you add one more, then the scale shifts, and what was yellow yesterday becomes green(ish) today.

 

Understand this. But why not using the quality gate settings in such cases? Green= quality gate criteria fulfilled; red=failed. If no quality gate condition or report exist make it grey. This would also be beneficial for metrics like size where you at least get an overview about folder/files and their size.

 

 Would anyway call it heatmaps?

 

All Measures / Coverage Measures: https://next.sonarqube.com/sonarqube/component_measures/metric/coverage/list?id=org.sonarsource.java%3Ajava

For me the word heatmap would be more descriptive than treemap.

 

In fact, the scale here is not coder-hours but plain issue count. "Overview" may not be the best name, but Technical Debt surely doesn't fit. It's possible that this chart will evolve, but nothing has been finalized.

 

For my understanding SQ should still be a tool to measure Technical Debt? So a chart to visualize the overall technical debt would be helpful.

 

Looking forward to the next LTS,

Günter

 

[Günter Wirth]

Hi,

we have problems with our integration test after this change.

Built-in quality profiles ... profiles provided by plugins are now read-only and automatically updated on plugin upgrade

https://jira.sonarsource.com/browse/SONAR-9303

Use case is: We are delivering rules with our plugin but not all are activated per default In the past it was possible that users were able to activate them afterwards or over REST API.
What's the idea to handle this in future?

Regards,
Günter

[Simon Brandhof]

Hi Günter,

Note that before 6.5 the new versions of your built-in profile were not applied to existing profiles. For example a new rule had to be manually activated, even if present in the plugin.

In 6.5 users can still administrate the Quality profiles they create. In order to be always up-to-date with built-in profile, then a user profile should inherit the built-in profile (see operation "Change Parent"). Changes on each new upgrade will be propagated.

Regards

--
You received this message because you are subscribed to the Google Groups "SonarQube" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sonarqube+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/sonarqube/df018317-fc91-422c-9cbe-720192181cf7%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Günter Wirth]

Hi Simon,

Note that before 6.5 the new versions of your built-in profile were not applied to existing profiles. For example a new rule had to be manually activated, even if present in the plugin.

Not sure if this was really a disadvantage? In older versions the admin could decide if and when new rules should get active. With this change a plugin update means also immediately a rule set change.

 ... then a user profile should inherit the built-in profile (see operation "Change Parent"). Changes on each new upgrade will be propagated.

Problem I see is that derived profiles can't deactivate parent rules. It's only allowed to activate additional rules?

So only solution to get old behaviour seems to be to copy a default profile. In this case full control over activations/deactivation is back.

POST api/qualityprofiles/copy?

Regards,