<commit_before># Monthly Release

NOTE: This is a guide used by the GitLab the company to release GitLab.
As an end user you do not need to use this guide.

The process starts 7 working days before the release.
The release manager doesn't have to perform all the work but must ensure someone is assigned.
The current release manager must schedule the appointment of the next release manager.
The new release manager should create overall issue to track the progress.
The release manager should be the only person pushing/merging commits to the x-y-stable branches.

## Release Manager

A release manager is selected that coordinates all releases the coming month,
including the patch releases for previous releases.
The release manager has to make sure all the steps below are done and delegated where necessary.
This person should also make sure this document is kept up to date and issues are created and updated.

## Take vacations into account

The time is measured in weekdays to compensate for weekends.
Do everything on time to prevent problems due to rush jobs or too little testing time.
Make sure that you take into account any vacations of maintainers.
If the release is falling behind immediately warn the team.

## Create an overall issue and follow it

Create an issue in the GitLab CE project. Name it "Release x.x" and tag it with
the `release` label for easier searching. Replace the dates with actual dates
based on the number of workdays before the release. All steps from issue
template are explained below:

```
### Xth: (7 working days before the 22nd)

- [ ] Triage the [Omnibus milestone]

### Xth: (6 working days before the 22nd)

- [ ] Determine QA person and notify this person
- [ ] Check the tasks in [how to rc1 guide](https://dev.gitlab.org/gitlab/gitlabhq/blob/master/doc/release/howto_rc1.md) and delegate tasks if necessary
- [ ] Merge CE `master` into EE `master` via merge request (#LINK)
- [ ] Create CE and EE RC1 versions (#LINK)
- [ ] Build RC1 packages

### Xth: (5 working days before the 22nd)

- [ ] Do QA and fix anything coming out of it (#LINK)
- [ ] Close the [Omnibus milestone]
- [ ] Prepare the [blog post]

### Xth: (4 working days before the 22nd)

- [ ] Update GitLab.com with RC1
- [ ] Create the regression issue in the CE issue tracker:

    > This is a meta issue to index possible regressions in this monthly release
    > and any patch versions.
    >
    > Please do not raise or discuss issues directly in this issue but link to
    > issues that might warrant a patch release. If there is a Merge Request
    > that fixes the issue, please link to that as well.
    >
    > Please only post one regression issue and/or merge request per comment.
    > Comments will be updated by the release manager as they are addressed.

- [ ] Tweet about RC1 release:

    > GitLab x.y.0.rc1 is available: https://packages.gitlab.com/gitlab/unstable
    > Use at your own risk. Please link regressions issues from
    > LINK_TO_REGRESSION_ISSUE

### Xth: (3 working days before the 22nd)

- [ ] Merge `x-y-stable` into `x-y-stable-ee`
- [ ] Check that everyone is mentioned on the [blog post] using `@all`
<commit_msg>Update monthly release template<commit_after># Monthly Release

NOTE: This is a guide used by the GitLab the company to release GitLab.
As an end user you do not need to use this guide.

The process starts 7 working days before the release.
The release manager doesn't have to perform all the work but must ensure someone is assigned.
The current release manager must schedule the appointment of the next release manager.
The new release manager should create overall issue to track the progress.
The release manager should be the only person pushing/merging commits to the x-y-stable branches.

## Release Manager

A release manager is selected that coordinates all releases the coming month,
including the patch releases for previous releases.
The release manager has to make sure all the steps below are done and delegated where necessary.
This person should also make sure this document is kept up to date and issues are created and updated.

## Take vacations into account

The time is measured in weekdays to compensate for weekends.
Do everything on time to prevent problems due to rush jobs or too little testing time.
Make sure that you take into account any vacations of maintainers.
If the release is falling behind immediately warn the team.

## Create an overall issue and follow it

Create an issue in the GitLab CE project. Name it "Release x.x" and tag it with
the `release` label for easier searching. Replace the dates with actual dates
based on the number of workdays before the release. All steps from issue
template are explained below:

```
### Xth: (7 working days before the 22nd)

- [ ] Triage the [Omnibus milestone]

### Xth: (6 working days before the 22nd)

- [ ] Determine QA person and notify this person
- [ ] Check the tasks in [how to rc1 guide](https://dev.gitlab.org/gitlab/gitlabhq/blob/master/doc/release/howto_rc1.md) and delegate tasks if necessary
- [ ] Merge CE `master` into EE `master` via merge request (#LINK)
- [ ] Create CE and EE RC1 versions (#LINK)
- [ ] Build RC1 packages

### Xth: (5 working days before the 22nd)

- [ ] Do QA and fix anything coming out of it (#LINK)
- [ ] Close the [Omnibus milestone]
- [ ] Prepare the [blog post]

### Xth: (4 working days before the 22nd)

- [ ] Update GitLab.com with RC1
- [ ] Create the regression issue in the CE issue tracker:

    ```
    This is a meta issue to index possible regressions in this monthly release
    and any patch versions.

    Please do not raise or discuss issues directly in this issue but link to
    issues that might warrant a patch release. If there is a Merge Request
    that fixes the issue, please link to that as well.

    Please only post one regression issue and/or merge request per comment.
    Comments will be updated by the release manager as they are addressed.
    ```

- [ ] Tweet about RC1 release:

    ```
    GitLab x.y.0.rc1 is available: https://packages.gitlab.com/gitlab/unstable
    Use at your own risk. Please link regressions issues from
    LINK_TO_REGRESSION_ISSUE
    ```

### Xth: (3 working days before the 22nd)

- [ ] Merge `x-y-stable` into `x-y-stable-ee`
- [ ] Check that everyone is mentioned on the [blog post] using `@all`

{'fraction_non_alphanumeric': 0.06228373702422145, 'fraction_numerical': 0.007549543881723813, 'mean_word_length': 3.682621502209131, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 15, 'https://': 4, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '883061', 'n_tokens_mistral': 1758, 'n_tokens_neox': 1666, 'n_words': 953}