Change the feature freeze details
This commit is contained in:
parent
4716cae4f8
commit
f3c34cde4e
27
PROCESS.md
27
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.
|
||||
|
||||
|
|
Loading…
Reference in New Issue