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

Releasing process updates #3911

wants to merge 7 commits into from

Conversation

codebien
Copy link
Contributor

What?

  • It updates the release process introducing the release branches.
  • It creates a dedicated template to release patch versions.

Why?

  • It doesn't freeze the master branch when the k6 repo is on feature freeze.
  • Patches and minor releases have the same process by tagging from a release branch. (Instead, now we tag from master for minor releases and from a hotfix branch for patches).

Related PR(s)/Issue(s)

@codebien codebien self-assigned this Aug 23, 2024
@codebien codebien requested a review from a team as a code owner August 23, 2024 12:27
@codebien codebien requested review from mstoykov and olegbespalov and removed request for a team August 23, 2024 12:27

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

oleiade
oleiade previously approved these changes Aug 27, 2024
Copy link
Member

@oleiade oleiade left a comment

Choose a reason for hiding this comment

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

Besides minor comments 🚀

Co-authored-by: Joan López de la Franca Beltran <[email protected]>
.github/ISSUE_TEMPLATE/hotfix-release.md Outdated Show resolved Hide resolved
.github/ISSUE_TEMPLATE/hotfix-release.md Outdated Show resolved Hide resolved
.github/ISSUE_TEMPLATE/release.md Outdated Show resolved Hide resolved
Copy link
Contributor

@olegbespalov olegbespalov left a comment

Choose a reason for hiding this comment

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

I generally don't oppose the proposal; we could try it. We might make our checklist statements closer to http://releaseflow.org, which is my understanding of our end goal.

The concrete example:
The current version says cherry-pick changes and it sounds (maybe to me) like the only possible way to go, whenever in release flow it more freedom version ensure this fix is applied (usually cherry-picked) to other branches where necessary

@codebien
Copy link
Contributor Author

Hey reviewers, please take another look 🙏

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants