k6 release v0.48.0

[olegbespalov]

Release Date:

December 6th 2023 (06.12.2023)

Release Activities

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-notes-v0.4x.0 long-lived branch and add a new release notes file using the available template to the repository's release notes folder.
  • https://github.com/grafana/k6/tree/release-notes-v0.48.0
• Go through the potential dependencies updates and create a dedicated PR if any of them is relevant to this release.
  • Update k6's dependencies #3386
  • Update dependency of the demo GRPC server & gofumpt #3387
  • grcp-demo-service: Update the transitive dependencies #3388
• Create a new release-v0.4x.0 long-lived branch on the grafana/k6-DefinitelyTyped fork repository.
  • https://github.com/grafana/k6-DefinitelyTyped/tree/version/0.48

Release Preparation

~ 1 week before the release date.

• Ensure all PRs in the k6-docs repository, related to new or modified functionalities introduced by the new version have been created.
  • Document new redis options k6-docs#1416
  • Document the K6_INFLUXDB_HTTP_PROXY k6-docs#1418
  • Suggest using k6 new instead of copying sample script k6-docs#1425
  • Option --profiling-enabled k6-docs#1417
  • Document k6/experimental/fs module k6-docs#1419
  • Document a new metrics restriction k6-docs#1426
  • Add k6 traces output option documentation k6-docs#1433
• Ensure all PRs in the k6 repository, part of the current milestone, have been merged.
• Open a PR with the release notes for the new version, and ask teams who might have contributed to the release (k6-browser, k6-chaos, k6-devrel teams, etc.) to contribute their notes and review the existing ones.
  • Release notes v0.48.0 #3458
• Share the release notes PR with the k6 open-source teams. Request contributions from all affected teams (browser, chaos, devrel, docs, etc.) and any other stakeholders involved in the new release.
• Open a separate PR for bumping the k6 Go project's version.
  • Bump the k6 version to v0.48.0 #3486
• 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.
  • [k6] Add type annotations for version v0.48.0  DefinitelyTyped/DefinitelyTyped#67771

~ 1 day before the release date.

• Ensure all PRs in the k6-docs repository, related to new or modified functionalities introduced by the new version have been created.
  • Document new redis options k6-docs#1416
  • Document the K6_INFLUXDB_HTTP_PROXY k6-docs#1418
  • Suggest using k6 new instead of copying sample script k6-docs#1425
  • Option --profiling-enabled k6-docs#1417
  • Document k6/experimental/fs module k6-docs#1419
  • Document a new metrics restriction k6-docs#1426
  • Add k6 traces output option documentation k6-docs#1433

Release Day

Documentation

• Open and merge a PR 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).
  • documentation for k6 v0.48 k6-docs#1445
• Ensure the k6 repository release notes PR contains the correct links to the docs.

In k6 repository

• Merge the PR bumping the k6 Go project's version.
  • Bump the k6 version to v0.48.0 #3486
• Merge the release notes PR.
  • Release notes v0.48.0 #3458
• Create and push a new tag of the form vX.Y.Z using git: git tag v0.4x.0 -m "v0.4x.0".

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.
• Close the release's milestone.

Wrapping Release

• Ensure the DefinitelyTyped/DefinitelyTyped PR(s) are merged.
  • [k6] Add type annotations for version v0.48.0  DefinitelyTyped/DefinitelyTyped#67771
• Update the k6 repository's .github/ISSUE_TEMPLATE/release.md in the event steps from this checklist were incorrect or missing.
  • Release process recent changes #3473

[inancgumus]

Shouldn't the k6-docs branch be named release-v0.48.0 instead of release-notes-v0.48.0? According to this. We've changed the branch name accordingly (also in this issue's description), but feel free to revert it if there is a misunderstanding.

Ideally, I suggest naming every branch the same to avoid confusion like this. Maybe like release-v0.48.0 for each repository (k6, k6-docs, and k6-DefinitelyTyped).

cc: @grafana/k6-core @grafana/k6-browser

[codebien]

Maybe like release-v0.48.0 for each repository (k6, k6-docs, and k6-DefinitelyTyped).

@inancgumus I agree with you, it would be easier for everyone to remember what to research for. Can you open a PR to change it on the template?

[inancgumus]

@codebien Sure: #3434.

[olegbespalov]

In my opinion, having the exact same branch name is not something urgent and essential. The most important part is to communicate how to find this branch properly, and this is done by just having the reference from this task.

However, at the end of the cycle, during the last activity of the reviewing process, we could return to #3434.