Commit e8f1bfaf authored by Robert Speicher's avatar Robert Speicher

Merge branch 'feature-freeze-exceptions' into 'master'

Describe process around cherry-picking during the feature freeze

See merge request !9075
parents 9d62fdfa d3333c34
...@@ -59,20 +59,38 @@ star, smile, etc.). Some good tips about code reviews can be found in our ...@@ -59,20 +59,38 @@ star, smile, etc.). Some good tips about code reviews can be found in our
## Feature Freeze ## Feature Freeze
On the 7th of each month, the stable branches for the upcoming release will On the 7th of each month, RC1 of the upcoming release is created and deployed to GitLab.com and the stable branch for this release is frozen, which means master is no longer merged into it.
be frozen for major changes. Merge requests may still be merged into master Merge requests may still be merged into master during this period,
during this period. By freezing the stable branches prior to a release there's but they will go into the _next_ release, unless they are manually cherry-picked into the stable branch.
no need to worry about last minute merge requests potentially breaking a lot of By freezing the stable branches 2 weeks prior to a release, we reduce the risk of a last minute merge request potentially breaking things.
things.
What is considered to be a major change is determined on a case by case basis as Once the stable branch is frozen, only fixes for regressions (bugs introduced in that same release)
this definition depends very much on the context of changes. For example, a 5 and security issues will be cherry-picked into the stable branch.
line change might have a big impact on the entire application. Ultimately the Any merge requests cherry-picked into the stable branch for a previous release will also be picked into the latest stable branch.
decision will be made by the maintainers and the release managers. These fixes will be released in the next RC (before the 22nd) or patch release (after the 22nd).
If you think a merge request should go into the upcoming release even though it does not meet these requirements,
you can ask for an exception to be made. Exceptions require sign-off from 3 people besides the developer:
1. a Release Manager
2. an Engineering Lead
3. an Engineering Director, the VP of Engineering, or the CTO
You can find who is who on the [team page](https://about.gitlab.com/team/).
Whether an exception is made is determined by weighing the benefit and urgency of the change
(how important it is to the company that this is released _right now_ instead of in a month)
against the potential negative impact
(things breaking without enough time to comfortably find and fix them before the release on the 22nd).
When in doubt, we err on the side of _not_ cherry-picking.
For example, it is likely that an exception will be made for a trivial 1-5 line performance improvement
(e.g. adding a database index or adding `includes` to a query), but not for a new feature, no matter how relatively small or thoroughly tested.
During the feature freeze all merge requests that are meant to go into the upcoming During the feature freeze all merge requests that are meant to go into the upcoming
release should have the correct milestone assigned _and_ have the label release should have the correct milestone assigned _and_ have the label
~"Pick into Stable" set. Merge requests without a milestone and this label will ~"Pick into Stable" set, so that release managers can find and pick them.
Merge requests without a milestone and this label will
not be merged into any stable branches. not be merged into any stable branches.
## Copy & paste responses ## Copy & paste responses
......
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