Releasing process updates #3911
Conversation
codebien
requested review from
mstoykov and
olegbespalov
and removed request for
a team
|
|
||
| #### Documentation | ||
|
|
||
| - [ ] If required, open and merge pull-request from `main` applying the changes to the affected version. |
There was a problem hiding this comment.
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.
Good question 👀 @heitortsergent do you maybe have insights on how you folks handle that in other projects?
There was a problem hiding this comment.
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.
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.
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.
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
left a comment
oleiade
left a comment
There was a problem hiding this comment.
Besides minor comments 🚀
Co-authored-by: Joan López de la Franca Beltran <[email protected]>
Co-authored-by: Oleg Bespalov <[email protected]>
olegbespalov
left a comment
olegbespalov
left a comment
There was a problem hiding this comment.
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 🙏 |
olegbespalov
left a comment
olegbespalov
left a comment
There was a problem hiding this comment.
It's probably stale, @codebien do you think we can close it?
|
@olegbespalov did we reach some shared consensus on what should be the hotfix path? Because this was one of the changes introduced. So we might re-align this pull request with the current status or close, but we still should have a practice documented for patching a version. |
I'm not aware of that |
|
Closing as this is now outdated |
6 participants
What?
Why?
Related PR(s)/Issue(s)