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.

Sign up for GitHub

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

Releasing process updates #3911

Show file tree
Hide file tree
Changes from 1 commit
Commits
Show all changes
7 commits
Select commit Hold shift + click to select a range
98e6c1e
Implement the release flow branching strategy
codebien Aug 23, 2024
d2895d8
Apply suggestions from code review
codebien Aug 30, 2024
eb106f5
Apply suggestions from code review
codebien Aug 30, 2024
85af08c
Text adjusted
codebien Aug 30, 2024
10e52ef
Relax the backporting policy
codebien Aug 30, 2024
e328391
Reverted the bump of the version to stay at the end of the cycle
codebien Aug 30, 2024
32ba97c
Integrated with dedicated patches
codebien Aug 30, 2024
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
44 changes: 44 additions & 0 deletions .github/ISSUE_TEMPLATE/hotfix-release.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,44 @@
---
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 generated from the latest minor release. It has the name in the form `release-v<major>.<minor>.x`.
codebien marked this conversation as resolved.
Show resolved Hide resolved

#### 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 •
edited
Loading

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: `git tag v0.5x.0 -m "v0.5x.0"`.
codebien marked this conversation as resolved.
Show resolved Hide resolved
- [ ] 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 for the new release.
codebien marked this conversation as resolved.
Show resolved Hide resolved

#### 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.

#### 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.
14 changes: 9 additions & 5 deletions .github/ISSUE_TEMPLATE/release.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -14,9 +14,10 @@ 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).
- [ ] 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).
codebien marked this conversation as resolved.
Show resolved Hide resolved
- [ ] 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 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-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,6 +26,8 @@ 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 a new release branch with the format `release-v0.<minor>.x` (e.g. `release-v0.51.x`)
- [ ] During the next two weeks, if any patch relevant for the release has been merged on `master` then
codebien marked this conversation as resolved.
Show resolved Hide resolved

#### ~ 1 week before the release date

Expand All @@ -35,7 +38,6 @@ labels: ["release"]
- [ ] 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.

#### ~ 1 day before the release date
Expand All @@ -51,10 +53,12 @@ labels: ["release"]

#### 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).
- [ ] Make sure all the patches have been cherry-picked on the release branch.
codebien marked this conversation as resolved.
Show resolved Hide resolved
- [ ] Merge the release notes PR.
- [ ] 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 relaese 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"`.
codebien marked this conversation as resolved.
Show resolved Hide resolved
- [ ] Delete the previous minor's relaese branch. Note, in a major version only the latest minor is actively maintained.
codebien marked this conversation as resolved.
Show resolved Hide resolved

#### Announcements

Expand Down