And here’s the consolidated Q&A from the webinar. Please open new threads for followup questions. There’s a large volume here, so I’ll start with a quick topic list:
LTS
Migrating to 8.9 LTS
Operating SonarQube
Editions
Branch and PR analysis & decoration
Security analysis and reporting
SonarLint
Languages
Other features and future development
In conclusion…
LTS
Q. What is LTS?
A. Literally, “LTS” means Long-Term Support. Figuratively, it means that we’ll patch this version for blocker bugs and vulnerabilities until the release of the next LTS version in approximately 18 months. We’ve put together an information page if you’d like more detail: https://sonarqube.org/downloads/lts/
Q. How do organizations decide whether to stay with the LTS or keep up with the latest releases?
A. Very large organizations in need of stability typically choose the LTS - a feature-complete, hardened package that comes with a commitment to fixing blocker bugs and vulnerabilities. On the other hand, organizations that have the ability to deal with more frequent change typically use latest versions, which are released approximately every 2 months. After all, Latest has the newest features, innovations, rules and improvements. But moving beyond the LTS means a commitment to keeping up with the latest versions as they’re released because only the LTS and Latest are supported.
Q. Analyzer upgrades are a bundled part of server upgrades now. So does adopting the LTS mean no analyzer upgrades for 18 months? What about false-positive fixes and bugs in the rules?
A. Users and organizations that choose the LTS typically do so for stability. Part of that is stability of the analysis. Having rule implementations get “smarter” mid-stream can be disruptive to some organizations. Thus, we’ve stabilized the underlying language analyses as part of the LTS promise. Just like for all other parts of the LTS, we will patch blocker bugs and vulnerabilities in the analyzers.
Q. Version 7.9 used to be the LTS. Since it’s not the LTS anymore, does that mean support is over?
A. Yes, and no. Since 7.9 is no longer the current LTS version, we won’t be issuing any more patches for it. However, if you’re on 7.9 you’re not totally on your own. For six months after the 8.9 release - so until approximately 4 Nov - we’ll “support” helping you migrate from 7.9 to 8.9.
Migrating to 8.9 LTS
Q. Is there a single document listing the differences - including deprecations and removals - between 7.9 and 8.9 LTS?
A. You may find the consolidated LTS-to-LTS Upgrade Notes helpful: https://docs.sonarqube.org/latest/setup/lts-to-lts-upgrade-notes/
Q. What are the migration steps from earlier versions?
A. First, check the requirements to make sure you’re caught up to the necessary versions of Java, the database &etc. From there, if you’re upgrading from version 7.9 or later, simply follow the standard Upgrade Guide. If you’re upgrading from a version older than 7.9, you’ll need to perform a multi-step upgrade. It too is detailed in the docs.
Q. Previous LTS-to-LTS upgrades have taken a long time. Are there many database changes for 8.9? Will this be a long migration?
A. We load tested the 7.9 to 8.9 migration with a 1.2Tb dataset. After multiple rounds of testing and tuning, the final migration test took 16 hours. You can find the specs in the relevant ticket: SONAR-14744
Q. We installed sonarqube from the zip file and now want to move to Docker. Is there any documentation on this migration ?
A. There’s no documentation on this migration because there’s really nothing to “migrate” from a SonarQube standpoint. Assuming this is a same-version migration, you simply configure your new instance to point to your existing database; shut the old instance down; and spin the new instance up. If it’s a version upgrade as well, then you only need to follow the standard upgrade guide.
Q. I’m on 8.8 - will upgrading to 8.9 give me much?
A. First, every version older than the current LTS is E.O.L. so at a minimum, upgrading puts you on a supported version. That “support” includes security hardening of SonarQube itself, including its build pipeline. Beyond that, every LTS version is essentially a hardening version. That means you’ll get lots of bug fixes and minor improvements. This community post goes into details: https://community.sonarsource.com/t/changes-from-8-8-to-8-9/43215/2.
Q. Do I need a new license key to upgrade from 7.9 to 8.9 LTS?
A. Your existing license key will work with the upgrade. No need to ask for a new one.
Q. You said in the webinar that 8.9 is a free upgrade. Will the 9.x versions be free upgrades too?
A. All upgrades - within the same edition - are free. So 7.9 Community Edition (CE) to 8.9 CE is free, 7.9 Developer Edition to 8.9 DE is free. 8.9 to 9.0, 9.1, and so on will be free too.
Q. We are planning our upgrade to the 8.9 LTS soon. However we are planning to migrate to a Cloud SaaS instance in Q3 2021. Would migrating to Cloud then become a setback?
A. If the plan is to move your SonarQube instance into the cloud, getting on to at least 8.9 is your best first step. However if the plan is to move to SonarCloud, then you should know that there’s no functlonality to import your existing data.
Q. Are there new rules in 8.9? And if so, will they be automatically applied?
A. Every new version contains new rules and rule improvements (i.e. existing rules get smarter) for at least one language. Cumulatively from 7.9 to 8.9 there are a lot of new rules and improvements. Many of those rules are added to the “Sonar way” profiles, so if you’re using those profiles you’ll automatically get the benefit. Otherwise, you can use the “Available Since” facet on the rules page (search by the day before your upgrade) to find the rules that are new to use.
To preview the effects of the new rules, try them first in a staging server, or construct test profiles and run tests on “dummy” projects (i.e. copies of your real projects with test projectKey values).
Q. What about my other components? Do I need to upgrade my scanners? SonarLint? The Build Wrapper?
A. It’s always best to use the latest components, and an LTS upgrade represents a good time to make sure all the parts of the ecosystem are up to date.
Operating SonarQube
Q. What is the performance improvement if we compare 8.5 with 8.9 versions ?
A. We did extensive testing (and iteration) of the upgrade from 7.9 to 8.9. You can find the results of our tests & optimizations here in SONAR-14744.
Q. Do you support the RDS database?
A. We support recent versions of PostreSQL, SQL Server and Oracle. More details in the docs.
Q. Can SonarSource review the rules in 3rd-party plugins to deprecate the ones that are replaced by your rules? Have you tested the plugin upgrades in the Marketplace?
A. Third-party plugins are owned and managed by their maintainers, and as such are outside SonarSource’s scope. In fact, that’s part of why we added limits and warnings around the use of 3rd-party plugins in this LTS. We believe the rules we offer out-of-the-box are sufficient without additional plugins. If there are rules you need that we don’t offer please open a new thread in the community to let us know!
Q. How do I get access to the analyzers to begin analyzing my projects?
A. SonarScanner for Gradle and SonarScanner for Maven only need to be invoked. The other scanners can be downloaded from our documentation: https://docs.sonarqube.org/latest/analysis/overview/
Q. What support is there for Kubernetes?
A. We offer an official Helm Chart for Community Edition, Developer Edition and Enterprise Edition, along with recommendations for use. (Details in the docs.) We expect support for Data Center Edition to come in the 9.x series.
Editions
Q. You’ve added a lot of features in 8.9. Which ones are available in Community Edition?
A. The vast majority of our functionality is available in Community Edition, including project onboarding and tutorials, the ability to fail the pipeline, SonarLint - including integration with Security Hotspots - Python support, and most of the new rules and upgraded functionalities in CE languages. Features related to Branch and PR analysis, as well as Taint Analysis are available in commercial editions.
Q. Is reporting available in Developer Edition along with Taint Analysis? Is there an overview of which features are available in which editions?
A. While Taint Analysis starts in Developer Edition, security reports are only available from Enterprise Edition. You can see the other features of each edition on the downloads page: https://www.sonarqube.org/downloads/
Q. How is SonarQube licensed?
A. SonarQube Community Edition is free and open source. Always. No matter how many lines of code you have.
SonarQube commercial editions are priced per year by Lines of Code (in the largest branch of each project) under analysis. For more information, please see
Q. I’m interested in purchasing a commercial license. How do I get started?
A. Thanks for asking! Please fill out our contact form, so someone from the Sales team can contact you directly. Alternately, you can request a free, 14-day trial license to try before you buy: https://www.sonarqube.org/developer-edition/
Branch and PR analysis & decoration
Q. How can I specify the default branch for each repository? We frequently have master identifed in Github but would like to treat the dev branch as the default one in SonarQube.
A. With project import, new projects show the same name for the main branch that’s used in your DevOps platform. So if it’s ‘Develop’ in GitHub, it’ll be ‘Develop’ in SonarQube.
Q. How are Security Hotspots marked ‘safe’ in a branch or PR treated at merge?
A. Security Hotspots marked safe, and issues marked Won’t Fix in a PR are propagated at merge. However, Security Hotspot and issue status marked in another branch is not propagated at merge.
Q. Does the pull request decoration include code coverage being available in Bitbucket Server’s pull request UI?
A. The coverage is summarized as part of the overall quality gate result shown in the Bitbucket UI.
Q. Does the LTS have pull request analysis and decoration in GitHub? What about other CI/CDs?
A. Yes, it does! When adding projects SonarQube will walk you through setting up PR analysis and decoration and its easier than ever. https://docs.sonarqube.org/latest/analysis/branch-pr-analysis-overview/
Q. Will PR analyses also work for parallel build tasks? And what are the requirements to make it work?
A. You can run as many in parallel as you’d like. Builds from the same project will be queued and processed sequentially on the SonarQube server. Builds from separate projects can be analyzed in parallel up to your max number of Compute Engine workers configured. See https://docs.sonarqube.org/latest/instance-administration/compute-engine-performance/ if running Enterprise Edition or above.
Q. Can PR analysis be used without PR decoration?
A. Yes; PR decoration is an additional feature and can be skipped.
Q. How is the new code determined for PRs?
A. Code that is added or updated after the branch point is considered “new” in a PR.
Q. Are there any changes to short-lived and long lived branches?
A. We consolidated all branches to be shown identically. Only Pull/Merge Requests are visualized in a manner like Short-lived Branches used to be (where only metrics prertaining to new or changed code are shown).
Security analysis and reporting
Q. Can I drop the other SAST tools I’m using and only use SonarQube?
A. We feel that our commercial analysis of Java, C#, PHP, Python, JavaScript, TypeScript, C and C++ give extremely valuable results. We’ve had many customers tell us they feel the same way and have switched from other tools. But don’t take our word for it. We encourage everyone to perform their own side-by-side comparisons, which you can easily do with a free, 14-day trial license, available from https://www.sonarqube.org/enterprise-edition/.
One note of caution: many people approach such comparisons by simply looking at raw issue counts or lists between SonarQube and the other tool: “X-tool found an issue on line 47 and SonarQube doesn’t.” When you find yourself in this situation, we ask that you take a close look to see whether any “missing” issues raised by the other tool are actually True (or False) Positives.
Q. What OWASP Top 10/SANS features are supported for C++, spelled out in a simplified format?
A. You can see all the rules for each language on our rules website: Rules explorer. To see the OWASP and SANS based rules take a look at the Tags dropdown for each language.
Q. Can I get reports on Security issues from SonarQube?
A. Enterprise Edition offers Security Reports covering OWASP Top 10, CWE Top 25, and the SonarSource categories. The top reports can be downloaded from SonarQube in PDF format. A free 14-day trial is available at https://www.sonarqube.org/enterprise-edition/.
Q. Does JavaScript SAST also cover TypeScript?
A. Yes! JavaScript and TypeScript are both covered by the SAST engine and considered tier-1 languages.
Q. Is the full feature set from RIPS included in Sonar?
A. We focused on incorporating the RIPS analysis techniques into SonarQube. The user experience retains its SonarQube style and features.
Q. There is a difference between SAST/OWASP support/capabilities between SonarCloud and SonarQube?
A. SonarCloud always has the most up-to-date analysis of any language. In that regard security analysis on SonarCloud is pretty much the same as what you can get in the LATEST version of commercial editions of SonarQube.
Q. Who should perform Security Hotspot review? Developers or a Security team? And how should review be organized?
A. We believe Security Hotspots are best handled by developers themselves, with the Security team available as backup to help resolve the tricky ones. The thinking is two-fold.
First, the Security Hotspot review process and interface is designed to help developers educate themselves on security principles and to make them more aware of what is / is not security-sensitive.
Second, we believe that only developers can truly affect Code Security. In that context, giving security-related feedback directly to developers just makes the most sense.
In terms of the mechanics of how to handle Security Hotspot review, ideally new Security Hotspots will be raised in pull request analysis (available in all commercial editions) and reviewed before merge. That keeps the review burden small and manageable.
Q. Any chance for mass operations for security hotspots? So far the only results produced have come from third party libs and generated code which we can’t really do anything about
A. This is exactly why we recommend you omit such code from analysis. The docs can help: https://docs.sonarqube.org/latest/project-administration/narrowing-the-focus/
Q. Is the ability to open a Security Hotspot in the IDE available in Community Edition? And which versions of SonarLint is this supported for?
A. Security Hotspots and all related features are available in Community Edition, and ‘Open in IDE’ is supported in all versions of SonarLInt.
Q. What was the reason behind deprecating the SANS Top 25?
A. The SANS Top 25 has been static for several years now, and industry experts agree that the CWE Top 25 is more current, and thus a better resource. We’ve added reports starting in Enterprise Edition for CWE Top 25 2019 and CWE Top 25 2020. With those replacements available, it just made sense to deprecate the out-dated SANS Top 25.
Q. Will you expand into other types of security analysis, such as SCA or DAST?
A. Thanks for the vote of confidence! Our ambition is fully focused on SAST right now. 
We feel that other tools for those functions are a great complement to what we offer, and they should be used in concert.
SonarLint
Q. What version of SonarLint should I be on for compatibility with SonarQube 8.9?
A. It’s always best to make sure you’re on the latest version. We’re continually upgrading and improving the features, so staying current ensures you’ll have the best possible experience.
Q. What are the plans for extending SonarLint support to other IDEs and to more languages in the already-supported IDEs?
A. Thanks for your confidence and eagerness! It’s always nice to feel wanted.
We’ve added support for CLion this year and also hope to support JetBrains Rider and PyCharm, as well as Codespaces. We also want to add TypeScript support to VisualStudio. Beyond that our goal is to enhance the experience of existing users.
Languages
Q. Does 8.9 LTS have improvements in regard to incremental analysis in C++ compared to 8.2?
A. Basic caching was added early in the 8.x series, but has improved over time. You’ll want to take the upgrade to make sure you’re benefiting from all the latest features and improvements.
Q. Will there be some kind of architectural rules available in the future or do we have to detect these issues with external libraries like ArchUnit?
A. We have no current plans to add this kind of rule.
Q. Does the LTS support the latest version of my language?
A. We’ve updated analysis to support the latest language versions as of the LTS.
Q. Which compilers does the expanded compiler support for C and C++ cover?
A. The full list of supported compilers is on our site: C++ Static Code Analysis & Security Review Tool | SonarQube
Q. What additional languages are you planning to support in the 9.x series?
A. We’re planning to add IaC analysis. There are no current plans for other languages. Please see the downloads page for the full list of supported languages per edition: https://www.sonarqube.org/downloads/.
Q. You added rules for test code quality for Java, PHP and C# in 8.9. Is C++ on the roadmap for this as well?
A. We have considered this, but are finding it difficult to identify what standards should be enforced in this area. If you have recommendations, please feel free to share them in the community!
Q. A few of the rules which were available in 7.9 have been removed or deprecated in 8.9. Are those rules no longer relevant? Have they been replaced with better rules?
A. In general, yes. Rules are deprecated when they no longer make sense for current development norms, or are fully replaceable by a better rule (and/or implementation). For questions about specific rules, feel free to open new threads in the community!
Other features and future development
Q.You said the LTS includes failed pipelines for everyone. How do I make that work?
A. Thanks for asking. The mechanics vary slightly depending on your context. You’ll find the details in the documentation.
Q. How can we import our coverage reports into Sonarqube?
A. We offer support for a broad array of coverage reports (Test Coverage & Execution | SonarQube Docs). If yours is not included, you can convert the output of your tool to our generic format and import it that way (Generic Test Data | SonarQube Docs).
Q. Does 8.9 LTS support export of reports as PDF?
A. PDF based reports at the Portfolio level and Security reports at the Project and Application level are supported in the Enterprise edition.
Q. Is SQ moving away from supporting SVN as a code repository?
A. We offer native support for both Git and SVN with no current plans to change that.
Q. How can I send my analysis results to my enterprise dashboards outside of SonarQube?
A. For additional integration like this SonarQube includes both webhooks and a full web api: Webhooks | SonarQube Docs and Web API | SonarQube Docs
Q. Are there plans to change how authentication tokens are handled?
A. That’s not currently on our road map, but we’re always considering new features.
Q. Is there a way to track the user activities in the logs? For example, how can we know who changed the Quality Gate?
A. It is possible via access log parsing to determine this. At the same time, we hope to tackle audit trailing as a topic for the 9.x series.
Q. When will SonarScanner have one way to scan all programming languages?
A. We would actually see that as a step backward. We provide specialized scanners for specialized environments in order to relieve users of the burden of deep analysis configuration. If anything, we would go further in the other direction (although we have no current plans for scanner expansion).
Q. Are there plans to expand the reporting capabilities in future versions?
A. We are planning to expand reporting in the 9.x series. The details haven’t been finalized yet.
Q. When will branches and New Code come to Portfolios?
A. We plan to add branch support and a New Code focus to Portfolios in the 9.x series.
Q. What is the status of [specific ticket]?
A. Our JIRA is the best source of ongoing information on specific tickets. Feel free to watch and vote for your favorite ones. If you do, you’ll automatically be notified of status changes.
In conclusion...
Q. The Security Hotspots looks darn good!
A. Thanks for the feedback!
Q. It indeed is very friendly to ops teams, thank you for the outstanding engineering
A. Thank you for the kind words!
Q. Awesome upgrade features, I’ll be running 8.9 next week.
A. Woo hoo! That’s great to hear! Our work here is done. 
