-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
base: master
Are you sure you want to change the base?
Conversation
|
||
#### Documentation | ||
|
||
- [ ] If required, open and merge pull-request from `main` applying the changes to the affected version. |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this 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]>
Co-authored-by: Oleg Bespalov <[email protected]>
There was a problem hiding this 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
Hey reviewers, please take another look 🙏 |
What?
Why?
Related PR(s)/Issue(s)