From 53dd61f4cf58190b0a0182def92c7ef5c692d633 Mon Sep 17 00:00:00 2001 From: "G. Ann Campbell" Date: Wed, 22 Aug 2018 07:51:05 -0400 Subject: [PATCH] SONAR-10576: Use 'New Code Period' in docs --- server/sonar-docs/src/pages/analysis/scm_integration.md | 2 +- server/sonar-docs/src/pages/branches/index.md | 4 ++-- server/sonar-docs/src/pages/branches/long-lived-branches.md | 4 ++-- server/sonar-docs/src/pages/branches/short-lived-branches.md | 4 ++-- server/sonar-docs/src/pages/fixing-the-water-leak.md | 4 ++-- server/sonar-docs/src/pages/quality-gates.md | 4 ++-- .../src/tooltips/quality-gates/quality-gate-conditions.md | 2 +- 7 files changed, 12 insertions(+), 12 deletions(-) diff --git a/server/sonar-docs/src/pages/analysis/scm_integration.md b/server/sonar-docs/src/pages/analysis/scm_integration.md index df984418238..8771b78b2f1 100644 --- a/server/sonar-docs/src/pages/analysis/scm_integration.md +++ b/server/sonar-docs/src/pages/analysis/scm_integration.md @@ -6,7 +6,7 @@ Collecting SCM data during code analysis can unlock a number of SonarQube featur * Automatic Issue Assignment * code annotation (blame data) in the Code Viewer -* SCM-driven detection of new code (to help with Fixing the Water Leak). Without SCM data, SonarQube determines new code using analysis dates (to timestamp modification of lines). +* SCM-driven detection of new code (to help with [Fixing the Water Leak](/fixing-the-water-leak)). Without SCM data, SonarQube determines new code using analysis dates (to timestamp modification of lines). ### Turning it on/off SCM integration requires support for your individual SCM provider. Git and SVN are supported by default. For other SCM providers, see the Marketplace. diff --git a/server/sonar-docs/src/pages/branches/index.md b/server/sonar-docs/src/pages/branches/index.md index e5fa3afb4db..76cd3c02f97 100644 --- a/server/sonar-docs/src/pages/branches/index.md +++ b/server/sonar-docs/src/pages/branches/index.md @@ -25,8 +25,8 @@ This corresponds to Pull/Merge Requests or Feature Branches. This kind of branch * will disappear quickly * will be merged rapidly to prevent integration issues * is developed for a given version, so the version does not change, - and there is no Leak Period concept as such; it's all leak period - tracks all the new issues related to the code that changed on it. + and there is no New Code period concept as such; it's all new code +* tracks all the new issues related to the code that changed on it. ![conceptual illustration of short-lived branches.](/images/short-lived-branch-concept.png) diff --git a/server/sonar-docs/src/pages/branches/long-lived-branches.md b/server/sonar-docs/src/pages/branches/long-lived-branches.md index 010edc13b9c..b806d2b6a21 100644 --- a/server/sonar-docs/src/pages/branches/long-lived-branches.md +++ b/server/sonar-docs/src/pages/branches/long-lived-branches.md @@ -18,9 +18,9 @@ During the **first analysis only**, issues (type, severity, status, assignee, ch Then, at each subsequent analysis of the long-lived branch, any new issue that comes from a short-lived branch automatically inherits the attributes (type, severity, ...) the issue had in the short-lived branch. A comment is added to the change log of the issue on the long-lived branch: "The issue had been copied from branch 'the short-live branch' to branch yyy". -## Leak Period +## New Code Period -Because long-lived branches will persist for a long time, you are likely to develop and release multiple versions from it, and so you can change the Leak Period of a long-lived branch in **Administration > Branches**. +Because long-lived branches will persist for a long time, you are likely to develop and release multiple versions from it, and so you can change the New Code period of a long-lived branch in **Administration > Branches**. ## Settings and Quality Profiles on Branches diff --git a/server/sonar-docs/src/pages/branches/short-lived-branches.md b/server/sonar-docs/src/pages/branches/short-lived-branches.md index 1fecddd78c9..d84f56a0ba0 100644 --- a/server/sonar-docs/src/pages/branches/short-lived-branches.md +++ b/server/sonar-docs/src/pages/branches/short-lived-branches.md @@ -27,9 +27,9 @@ The issues visible on the short-lived branch are the new issues corresponding to Modified files are determined based on the checksum of each file on the sonar.branch.target and the short-lived branch. -## Leak Period +## New Code Period -The ephemeral nature of short-lived branches means no explicit Leak Period is necessary; it's all new code. Thus, no "new code" data is available for a short-lived branch. +The ephemeral nature of short-lived branches means no explicit New Code Period is necessary; it's all new code. ## Settings and Quality Profiles on Branches diff --git a/server/sonar-docs/src/pages/fixing-the-water-leak.md b/server/sonar-docs/src/pages/fixing-the-water-leak.md index 95eb6e0d904..6158b2ff23c 100644 --- a/server/sonar-docs/src/pages/fixing-the-water-leak.md +++ b/server/sonar-docs/src/pages/fixing-the-water-leak.md @@ -31,6 +31,6 @@ As a bonus, the code that gets changed the most has the highest maintainability, SonarQubeSonarCloud offers two main tools to help you find your leaks: -* Leak Period metrics show the variance in your measures between the current code and a specific point you choose in its history, typically the `previous_version` -* New Code is primarily detected based on SCM "blame" data (starting from the first analysis within your Leak Period), with fallback mechanisms when needed. See SCM integration for more details. +* New Code metrics show the variance in your measures between the current code and a specific point you choose in its history, typically the `previous_version` +* New Code is primarily detected based on SCM "blame" data starting from the first analysis within your New Code Period (formerly the "Leak Period"), with fallback mechanisms when needed. See [SCM integration](/analysis/scm-integration) for more details. * [Quality Gates](/quality-gates) allow you to set boolean thresholds against which your code is measured. Use them with differential metrics to ensure that your code quality moves in the right direction over time. diff --git a/server/sonar-docs/src/pages/quality-gates.md b/server/sonar-docs/src/pages/quality-gates.md index 49fc7529a4b..9d1cdda2dc2 100644 --- a/server/sonar-docs/src/pages/quality-gates.md +++ b/server/sonar-docs/src/pages/quality-gates.md @@ -23,7 +23,7 @@ Which is why you can define as many quality gates as you wish. Quality Gates are ## Use the Best Quality Gate Configuration -The quality gate "Sonar way" is provided by SonarSource, activated by default and considered as built-in and so read-only. It represents our view of the best way to implement the Fixing the Water Leak concept. At each SonarQube release, we adjust automatically this default quality gate according to SonarQube's capabilities. +The quality gate "Sonar way" is provided by SonarSource, activated by default and considered as built-in and so read-only. It represents our view of the best way to implement the [Fixing the Water Leak](/fixing-the-water-leak) concept. At each SonarQube release, we adjust automatically this default quality gate according to SonarQube's capabilities. Three metrics allow you to enforce a given Rating of Reliability, Security and Maintainability, not just overall but also on new code. These metrics are recommended and come as part of the default quality gate. We strongly advise you to adjust your own quality gates to use them to make feedback more clear to your developers looking at their quality gate on their project page. @@ -58,7 +58,7 @@ To manage quality gates, go to **[Quality Gates](/#sonarqube#/quality_gates)** ( Each Quality Gate condition is a combination of: * measure -* period: **Value** (to date) or **Leak** (differential value over the Leak period) +* period: **Value** (to date) or **New Code** (differential value over the New Code period) * comparison operator * warning value (optional) * error value (optional) diff --git a/server/sonar-docs/src/tooltips/quality-gates/quality-gate-conditions.md b/server/sonar-docs/src/tooltips/quality-gates/quality-gate-conditions.md index e961eeb17f6..3df434d5d03 100644 --- a/server/sonar-docs/src/tooltips/quality-gates/quality-gate-conditions.md +++ b/server/sonar-docs/src/tooltips/quality-gates/quality-gate-conditions.md @@ -1,4 +1,4 @@ -For each Quality Gate condition you must choose the metric to be tested, the threshold at which to raise a warning or error, and whether or not to apply the condition to all code or only to Leak Period code (irrelevant for conditions "on New Code"). +For each Quality Gate condition you must choose the metric to be tested, the threshold at which to raise a warning or error, and whether or not to apply the condition to all code or only to New Code period (irrelevant for conditions "on New Code"). --- -- 2.39.5