lots of release process doc tweaks #2832
Conversation
- add outcomes for all H4s (we may be able to remove some similar material from "body" content) - mention that svn is needed - clarify relationship to PR and PR checklist in a few places - we have 2 docs to follow now, which could be confusing - clarify release metadata step - this is metadata, not version number - clarify relationship to woo core - add dev blog post as final happy 🎉 step
haszari
requested review from
mikejolley and
nerrad
and removed request for
a team
|
Size Change: 0 B Total Size: 1.59 MB ℹ️ View Unchanged
|
There was a problem hiding this comment.
I have a couple minor suggested edits but other than that, this is a good improvement and we can get this merged in.
I agree with your other notes about future improvements but I'd like to hold off implementing any of that until the automation is done. Much of this will be simplified and be redundant once the automation lands and we can probably end up with a much more concise document that just has a checklist.
I really appreciate your attention to detail for the release process Rua, it definitely helps each time we do releases 👏
| #### Create pull request for updating the package in WooCommerce core. | ||
|
|
||
| If the tagged release should be updated in WooCommerce core, do this immediately following our release. | ||
| All releases (except RCs, betas etc) should be included in WooCommerce core. We do this by adding a PR on WooCommerce Core repo immediately after our release is completed. |
There was a problem hiding this comment.
| All releases (except RCs, betas etc) should be included in WooCommerce core. We do this by adding a PR on WooCommerce Core repo immediately after our release is completed. | |
| All releases (except pre-releases) should be included in WooCommerce core. We do this by adding a PR on WooCommerce Core repo immediately after our release is completed. |
There was a problem hiding this comment.
Leaving this as is – all releases except pre-releases is less clear in my opinion.
There was a problem hiding this comment.
is less clear in my opinion.
How so? Aren't RCs, betas, pre-releases? The concern I have is the etc you tacked on there. What is etc? Also, the Github releases tab explicitly has a pre-release indicator.
There was a problem hiding this comment.
We can take off the etc - let's revisit this as we iterate.
Co-authored-by: Darren Ethier <[email protected]>
Sounds good! Where are we tracking the automation goals/project/todos by the way? Perhaps I can help with that. |
here. I've currently got an in progress pull locally that I haven't pushed yet, as soon as I have the basics (creating a pull request) I'll push it. Then other items from the issue can be done in individual pulls. |
Have added this stuff:
Other ideas for improving this doc
One other thing that we might want to do - move the cherry picking / branch stuff to an appendix, it's really big and unwieldy, and necessary to skip over 2/3rds of it each release.
This bit, these three H5 sections: https://github.com/woocommerce/woocommerce-gutenberg-products-block/blob/2a6a0c05be5608e0fa51a7c92705fe93df94475a/docs/releases/handling-releases.md#patch-releases-against-latest-main-branch
Overall this doc is getting quite big, especially alongside the checklist in PR. Maybe we can make a smaller numbered list version and move some of the detail out to appendix section.
Also would be good to add info about the release schedule (every 2 weeks, release by end of wednesday), and the typical timeframe for doing a release. E.g. small releases should take no more than half day, bigger releases you might want to get started ASAP on the monday. (?)