github.com/grafana/pyroscope@v1.18.0/docs/internal/RELEASE.md (about)

     1  # Release Process
     2  
     3  ## Automatic Release Process
     4  
     5  1. Update [release notes](#release-notes)
     6  2. Create a new branch for the release (e.g., `release/vX.Y`). Make sure the release notes are present on this branch or
     7  [backported](#backport) later.
     8  3. Create the tag for the release (e.g., `vX.Y.Z`)
     9  4. Push the release branch and tag to the remote. Note that the tag will kick off a real release via goreleaser.
    10  5. Create a GitHub label for backports:
    11  
    12     ```gh label create "backport release/vX.Y" -d "This label will backport a merged PR to the release/vX.Y branch" -c "#0052cc"```
    13  
    14  > [!IMPORTANT]
    15  > The release branch should only contain the major (X) and minor (Y) version, but not the patch level (Z), for example:
    16  >
    17  > ✅ Correct: `release/v1.3`
    18  >
    19  > ⚠️  Incorrect: `release/v1.3.0`
    20  
    21  The CI will automatically handle the build and create a draft GitHub release.
    22  
    23  Once ready, you can edit and publish the draft release on GitHub.
    24  
    25  Please do not delete GitHub releases that were once public.
    26  
    27  ### Release notes
    28  
    29  The list of changes from the GitHub release form the basis of the public-facing release notes. Release notes are added to the [public Pyroscope documentation](https://grafana.com/docs/pyroscope/latest/release-notes/). These release notes follow the same pattern for each release:
    30  
    31  1. Copy the previous release's page (i.e., V1-3.md) to the new release number. Change the version information and [page weight](https://grafana.com/docs/writers-toolkit/write/front-matter/#weight) in the file's frontmatter.
    32  2. Update the page title (Version x.x release notes) and add a few sentences about the main updates in the release.
    33  3. Add a Features and enhancements section with list of updates. Refer to previous release notes for examples.
    34  4. (optional) Add a Breaking changes section with a list of these changes and their impact (this section can also be used to update the [Upgrade page](https://grafana.com/docs/pyroscope/latest/upgrade-guide/)).
    35  5. Add a Bug fixes section with a list of updates.
    36  6. Add a Documentation updates section with a list of updates.
    37  
    38  For help writing release notes, refer to the [Writers' Toolkit](https://grafana.com/docs/writers-toolkit/write/).
    39  
    40  ### Helm charts update
    41  
    42  Merge a PR that bumps the chart version in the main branch (no tagging required), the CI will automatically publish the chart to the [helm repository](https://grafana.github.io/helm-charts). 
    43  
    44  ## Backport
    45  
    46  A PR to be backported must have the appropriate `backport release/vX.Y` label(s) AND one of [these expected labels](https://github.com/grafana/grafana-github-actions/blob/7d2b4af1112747f82e12adfbc00be44fecb3b616/backport/backport.ts#L16):
    47  `['type/docs', 'type/bug', 'product-approved', 'type/ci']`. Note that these labels must be present before the PR is merged.
    48  
    49  [Example backport PR](https://github.com/grafana/pyroscope/pull/4352)
    50  
    51  ## Patch releases
    52  
    53  Any bugfixes or other entries should be added to the existing release notes for that version under a new heading with
    54  the version number. The changes should be on the appropriate release branch.
    55  
    56  Once merged, a `vX.Y.Z` patch release tag must be created and pushed to remote to create a new release.
    57  
    58  > [!WARNING]
    59  > If you are releasing a patch version, for an older major/minor version (example:
    60  > you are releasing `v1.15.2`, but the current latest release is `v1.16.0`),
    61  > you need to make sure the release's actions to publish a `:latest` docker
    62  > image tag and a `home-brew` formula are removed:
    63  >
    64  > This can be done by updating `release.yml` in the previous release branches to set `$IMAGE_PUBLISH_LATEST=false`.
    65  
    66  ## Manual Release Process
    67  
    68  The release process uses [goreleaser](https://goreleaser.com/scm/github/?h=github#github) and can be configured
    69  using the [.goreleaser.yaml](./.goreleaser.yaml).
    70  
    71  To create a new release first prepare the release using:
    72  
    73  ```bash
    74  make release/prepare
    75  ```
    76  
    77  This will build and packages all artifacts without pushing or creating the GitHub release.
    78  
    79  Once you're ready you can then tag your release.
    80  
    81  ```bash
    82  git tag v0.1.0
    83  ```
    84  
    85  And finally push the release using:
    86  
    87  ```bash
    88  make release
    89  ```
    90  
    91  > Make sure to have a [GitHub Token](https://goreleaser.com/scm/github/?h=github#github) `GITHUB_TOKEN` correctly set.
    92  
    93  Make sure to create the release notes and CHANGELOG for any manual release.