summaryrefslogtreecommitdiff
path: root/PROCESS.md
diff options
context:
space:
mode:
authorMarin Jankovski <marin@gitlab.com>2019-06-12 13:48:59 +0000
committerYorick Peterse <yorickpeterse@gmail.com>2019-06-12 13:48:59 +0000
commitf3c34cde4e168c29a3d567f8282ca9d57a62b01e (patch)
tree477a902e71ea8948427110f89bfe7661b19f9a39 /PROCESS.md
parent4716cae4f8339a1668a11e7397c94ee468d2aead (diff)
downloadgitlab-ce-f3c34cde4e168c29a3d567f8282ca9d57a62b01e.tar.gz
Change the feature freeze details
Diffstat (limited to 'PROCESS.md')
-rw-r--r--PROCESS.md27
1 files changed, 9 insertions, 18 deletions
diff --git a/PROCESS.md b/PROCESS.md
index 3c40f658070..9e971ef7531 100644
--- a/PROCESS.md
+++ b/PROCESS.md
@@ -64,7 +64,7 @@ The milestone of an issue that is currently being worked on by a community contr
should not be set to a named GitLab milestone (e.g. 11.7, 11.8), until the associated
merge request is very close to being merged, and we will likely know in which named
GitLab milestone the issue will land. There are many factors that influence when
-a community contributor finishes an issue, or even at all. So we should set this
+a community contributor finishes an issue, or even at all. So we should set this
milestone only when we have more certainty.
Note this only applies to issues currently assigned to community contributors. For
@@ -86,21 +86,12 @@ star, smile, etc.). Some good tips about code reviews can be found in our
## Feature freeze on the 7th for the release on the 22nd
-After 7th at 23:59 (Pacific Time Zone) of each month, stable branch and RC1
-of the upcoming release (to be shipped on the 22nd) is created and deployed to GitLab.com.
-The stable branch is frozen at the most recent "qualifying commit" on master.
-A "qualifying commit" is one that is pushed before the feature freeze cutoff time
-and that passes all CI jobs (green pipeline).
+The feature freeze on the 7th has been discontinued. [Transition period overview]
+describes the change to this process. During the transition period, the only guarantee that
+a change will be included in the release on the 22nd is if the change has been
+deployed to GitLab.com prior to this date.
-Merge requests may still be merged into master during this
-period, but they will go into the _next_ release, unless they are manually
-cherry-picked into the stable branch.
-
-By freezing the stable branches 2 weeks prior to a release, we reduce the risk
-of a last minute merge request potentially breaking things.
-
-Any release candidate that gets created after this date can become a final
-release, hence the name release candidate.
+[Transition period]: https://gitlab.com/gitlab-org/release/docs/blob/21cbd409dd5f157fe252f254f3e897f01908abe2/general/deploy/auto-deploy-transition.md#transition
### Feature flags
@@ -108,15 +99,15 @@ Merge requests that make changes hidden behind a feature flag, or remove an
existing feature flag because a feature is deemed stable, may be merged (and
picked into the stable branches) up to the 19th of the month. Such merge
requests should have the ~"feature flag" label assigned, and don't require a
-corresponding exception request to be created.
+corresponding exception request to be created.
-A level of common sense should be applied when deciding whether to have a feature
+A level of common sense should be applied when deciding whether to have a feature
behind a feature flag off or on by default.
The following guidelines can be applied to help make this decision:
* If the feature is not fully ready or functioning, the feature flag should be disabled by default.
-* If the feature is ready but there are concerns about performance or impact, the feature flag should be enabled by default, but
+* If the feature is ready but there are concerns about performance or impact, the feature flag should be enabled by default, but
disabled via chatops before deployment on GitLab.com environments. If the performance concern is confirmed, the final release should have the feature flag disabled by default.
* In most other cases, the feature flag can be enabled by default.