Commit 9a16fde7 authored by Joseph Jose's avatar Joseph Jose Committed by Fiona Neill

Fix Vale issues for administration/package_information/deprecation_policy.md

parent a9167729
......@@ -16,18 +16,18 @@ setup, various configuration requires removal.
### Policy
The Omnibus GitLab package will retain configuration for at least **one major**
version. We cannot guarantee that deprecated configuration
will be available in the next major release. See [example](#example) for more details.
The Omnibus GitLab package retains configuration for at least **one major**
version. We can't guarantee that deprecated configuration
is available in the next major release. See [example](#example) for more details.
### Notice
If the configuration becomes obsolete, we will announce the deprecation:
If the configuration becomes obsolete, we announce the deprecation:
- via release blog post on `https://about.gitlab.com/blog/`. The blog post item
will contain the deprecation notice together with the target removal date.
contains the deprecation notice together with the target removal date.
- via installation/reconfigure output (if applicable).
- via official documentation on `https://docs.gitlab.com/`. The documentation update will contain the corrected syntax (if applicable) or a date of configuration removal.
- via official documentation on `https://docs.gitlab.com/`. The documentation update contains the corrected syntax (if applicable) or a date of configuration removal.
### Procedure
......@@ -82,16 +82,16 @@ The final comment in the issue **has to have**:
## Example
User configuration available in `/etc/gitlab/gitlab.rb` was introduced in GitLab version 10.0, `gitlab_rails['configuration'] = true`. In GitLab version 10.4.0, a new change was introduced that requires rename of this configuration option. New configuration option is `gitlab_rails['better_configuration'] = true`. Development team will translate the old configuration into new one
and trigger a deprecation procedure.
User configuration available in `/etc/gitlab/gitlab.rb` was introduced in GitLab version 10.0, `gitlab_rails['configuration'] = true`. In GitLab version 10.4.0, a new change was introduced that requires rename of this configuration option. New configuration option is `gitlab_rails['better_configuration'] = true`. Development team translates the old configuration into a new one
and triggers a deprecation procedure.
This means that these two configuration
options will both be valid through GitLab version 10. In other words,
options are valid through GitLab version 10. In other words,
if you still have `gitlab_rails['configuration'] = true` set in GitLab 10.8.0
the feature will continue working the same way as if you had `gitlab_rails['better_configuration'] = true` set.
However, setting the old version of configuration will print out a deprecation
the feature continues working the same way as if you had `gitlab_rails['better_configuration'] = true` set.
However, setting the old version of the configuration prints out a deprecation
notice at the end of installation/upgrade/reconfigure run.
With GitLab 11, `gitlab_rails['configuration'] = true` will no longer work and you will have to manually change the configuration in `/etc/gitlab/gitlab.rb` to the new valid configuration.
In GitLab 11, `gitlab_rails['configuration'] = true` no longer works and you must manually change the configuration in `/etc/gitlab/gitlab.rb` to the new valid configuration.
**Note** If this configuration option is sensitive and can put integrity of the installation or
data in danger, installation/upgrade will be aborted.
data in danger,the installation or upgrade is aborted.
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment