Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Releasing process updates #3911

Open
wants to merge 7 commits into
base: master
Choose a base branch
from
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
48 changes: 48 additions & 0 deletions .github/ISSUE_TEMPLATE/hotfix-release.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,48 @@
---
name: k6 Hotfix release
about: Bugs or security issues have been identified and they requires a patch release.
title: 'k6 hotfix release v<major>.<minor>.<patch>'
labels: ["release"]
---

**Release Date**:

25th May 2024 << TODO: WRITE HERE THE UPDATED RELEASE DATE

## Release Activities

Note, the assumption is a minor branch release already exists from the latest minor release. This branch is named in the format `release-v<major>.<minor>.x`.

#### Documentation

- [ ] If required, open and merge pull-request from `main` applying the changes to the affected version.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Strictly speaking, that's outside the scope of this PR but... what's the plan for docs?
Have a folder per minor? Like: v1.0.x, v1.1.x, etc?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good question 👀 @heitortsergent do you maybe have insights on how you folks handle that in other projects?

Copy link
Contributor

@heitortsergent heitortsergent Aug 27, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't have insights into how other projects handle minor versions, and we also handle versions differently than them (folders vs branches).

@jdbaldry would you have any insight here? Is it just a matter of renaming/creating folders for minor versions?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure I understand, sorry. Are you not already maintaining a directory of documentation per minor version of k6?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh yes, I misread it too, I'm sorry. I thought this was in case we had to release a patch version.

For other projects, they would just have a branch for each minor version, which is the equivalent of our folders in k6-docs. Is that right @jdbaldry?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, most repositories have long-lived version branches for future patching and such, where the docs are maintained alongside the code. Since grafana/k6-docs is a docs-only repository, it's simpler to just have directories in the main branch instead.


#### In k6 repository, if the defect affects the latest release and the `master` branch

- [ ] Open, get approvals and merge on `master` the patch for the defect.
codebien marked this conversation as resolved.
Show resolved Hide resolved
- [ ] Open, get approvals and merge on `master` the release notes. Ensure that all merged pull-requests are referenced.
- [ ] Switch on the release branch and cherry-pick the following changes:
1. the patch for the defect
2. the release notes
joanlopez marked this conversation as resolved.
Show resolved Hide resolved
- [ ] Open, get approvals and merge on the already existing release branch a separate pull-request for bumping [the k6 Go project's version](https://github.com/grafana/k6/blob/master/lib/consts/consts.go#L11-L12). Note, `master` should be already on a next major/minor version.
- [ ] Pull locally the previously merged changes.
- [ ] Create and push a new tag of the form `vX.Y.Z` using git. For instance, if the current release is v0.52, the command could look like `git tag v0.52.1 -m "v0.52.1"` if this is the first hotfix.
- [ ] If the defect affects DefinitelyTyped's definitions, open a pull request in the `DefinitelyTyped/DefinitelyTyped` repository by creating a branch on the `grafana/k6-DefinitelyTyped` fork, to update the k6 type definitions.

#### In k6 repository, if the defect affects the latest release but not the `master` branch

The steps are the same as the previous, with the unique exception that the patch pull request has to be directly merged against the release branch instead of being cherry-picked.

#### In k6 repository, if the defect affects the latest release and the `master` branch but they are not anymore the same compatible code.

The union of the previous steps have to be executed, where the changes have to be applied independently to both branches without cherry-picking. Each version get a dedicated patch.

#### Announcements

- [ ] Publish a link to the new GitHub release in the #k6-changelog channel.
- [ ] Notify the larger team in the #k6 channel, letting them know that the release is published.

## Wrapping Release

- [ ] Ensure the `DefinitelyTyped/DefinitelyTyped` PR(s) are merged.
- [ ] Update the k6 repository's `.github/ISSUE_TEMPLATE/hotfix-release.md` in the event steps from this checklist were incorrect or missing.
29 changes: 16 additions & 13 deletions .github/ISSUE_TEMPLATE/release.md
Original file line number Diff line number Diff line change
Expand Up @@ -14,9 +14,9 @@ labels: ["release"]
### At the beginning of the cycle

- [ ] Obtain the Release coordinator's contact from the `@k6-browser` team and co-assign the issue to them.
- [ ] Create a new `release-v0.5x.0` long-lived branch and add a new release notes file using the available [template](https://github.com/grafana/k6/blob/master/release%20notes/template.md) to the [repository's `release notes` folder](https://github.com/grafana/k6/blob/master/release%20notes).
- [ ] Go through the potential [dependencies updates](https://github.com/grafana/k6/blob/master/Dependencies.md) and create a dedicated PR if any of them is relevant to this release.
- [ ] Create a new `release-v0.5x.0` long-lived branch on the [grafana/k6-DefinitelyTyped](https://github.com/grafana/k6-DefinitelyTyped) fork repository.
- [ ] Create a new `release-notes-v<major>.<minor>.<patch>` (e.g. `release-notes-v0.51.0`) long-lived branch and add a new release notes file using the available [template](https://github.com/grafana/k6/blob/master/release%20notes/template.md) to the [repository's `release notes` folder](https://github.com/grafana/k6/blob/master/release%20notes).
- [ ] Go through the potential [dependencies updates](https://github.com/grafana/k6/blob/master/Dependencies.md) and create a dedicated pull-request if any of them is relevant to this release.
- [ ] Create a new `release-v<major>.<minor>.<patch>` (e.g. `release-v0.51.0`) long-lived branch on the [grafana/k6-DefinitelyTyped](https://github.com/grafana/k6-DefinitelyTyped) fork repository.
- [ ] Bump the version in [types/k6/package.json](https://github.com/grafana/k6-DefinitelyTyped/blob/master/types/k6/package.json#L4) to the next one.

### Release Preparation
Expand All @@ -25,18 +25,19 @@ labels: ["release"]

- [ ] Ensure that all pull-requests from a release milestone are merged.
- [ ] Ensure that browser and other experimental modules (if needed) have been updated to their latest version.
- [ ] Open and merge a pull-request for bumping [the k6 Go project's version](https://github.com/grafana/k6/blob/master/lib/consts/consts.go#L11-L12).
- [ ] Open a new release branch with the format `release-v0.<minor>.x` (e.g. `release-v0.51.x`). Note, if during the next two weeks, any patch relevant for the release is merged on `master` then remember to cherry-pick it on the release branch.

#### ~ 1 week before the release date

- [ ] Ensure that all merged pull-requests referenced in the release notes are linked to the release milestone.
- [ ] Ensure all pull-requests in the `k6-docs` repository, related to new or modified functionalities introduced by the new version have been created.
- [ ] Ensure all PRs in the k6 repository, part of the current [milestone](https://github.com/grafana/k6/milestones), have been merged.
- [ ] Open a PR with the release notes for the new version
- [ ] Ensure all pull-requests in the k6 repository, part of the current [milestone](https://github.com/grafana/k6/milestones), have been merged.
- [ ] Open a pull-request with the release notes for the new version
- [ ] Ask teams who might have contributed to the release (k6-browser, k6-ecosystem, k6-docs, k6-devrel teams, etc.) to contribute their notes and review the existing ones.
- [ ] Remember to mention and thank [external contributors](https://github.com/search?q=user%3Agrafana+repo%3Ak6+milestone%3A%22v0.51.0%22+-author%3Amstoykov+-author%3Aoleiade+-author%3Ana--+-author%3Acodebien+-author%3Aolegbespalov+-author%3Aandrewslotin+-author%3Ajoanlopez+-author%3Aankur22+-author%3Ainancgumus+-author%3Aszkiba+-author%3Adependabot%5Bbot%5D&type=pullrequests). <-- Update the query with the correct milestone version.
- [ ] Share the release notes PR with the k6 open-source teams. Request contributions from all affected teams (k6-browser, k6-chaos, k6-docs, k6-devrel, etc.) and any other stakeholders involved in the new release.
- [ ] Open a separate pull-request for bumping [the k6 Go project's version](https://github.com/grafana/k6/blob/master/lib/consts/consts.go#L11-L12).
- [ ] Open a PR in the `DefinitelyTyped/DefinitelyTyped` repository, using the release branch created in the grafana/k6-DefinitelyTyped fork, to update the k6 type definitions for the new release.
- [ ] Share the release notes pull-request with the k6 open-source teams. Request contributions from all affected teams (k6-browser, k6-chaos, k6-docs, k6-devrel, etc.) and any other stakeholders involved in the new release.
- [ ] Open a pull-request in the `DefinitelyTyped/DefinitelyTyped` repository, using the release branch created in the grafana/k6-DefinitelyTyped fork, to update the k6 type definitions for the new release.

#### ~ 1 day before the release date

Expand All @@ -47,14 +48,16 @@ labels: ["release"]
#### Documentation

- [ ] Open and merge a pull-request from `main` in the `k6-docs` repository, copying the current k6's `next` to a folder named with the k6 version (e.g. `v0.48.x`).
- [ ] Ensure the k6 repository release notes PR contains the correct links to the docs.
- [ ] Ensure the k6 repository release notes pull-request contains the correct links to the docs.

#### In k6 repository

- [ ] Merge the PR bumping [the k6 Go project's version](https://github.com/grafana/k6/blob/master/lib/consts/consts.go#L11-L12).
- [ ] Merge the release notes PR.
- [ ] Ensure that all the patches have been cherry-picked to other branches where necessary. Or, if they are dedicated for the release branch that they have been merged.
- [ ] Merge the release notes pull-request.
- [ ] Pull locally the previously merged changes.
- [ ] Create and push a new tag of the form `vX.Y.Z` using git: `git tag v0.5x.0 -m "v0.5x.0"`.
- [ ] Switch on the release branch then cherry-pick the release notes changes.
- [ ] Directly from the release branch, create and push a new tag of the form `v<major>.<minor>.<patch>` using git: `git tag v0.5x.0 -m "v0.5x.0"`.
- [ ] Delete the previous minor's release branch. Note, in a major version only the latest minor is actively maintained.

#### Announcements

Expand All @@ -64,5 +67,5 @@ labels: ["release"]

## Wrapping Release

- [ ] Ensure the `DefinitelyTyped/DefinitelyTyped` PR(s) are merged.
- [ ] Ensure the `DefinitelyTyped/DefinitelyTyped` pull-request(s) are merged.
- [ ] Update the k6 repository's `.github/ISSUE_TEMPLATE/release.md` in the event steps from this checklist were incorrect or missing.