Github Workflow Changes for Release Note Process #4961
Conversation
| @@ -1,9 +1,8 @@ | |||
| ## Writing DevTools release notes | |||
| ## Generating Release notes | |||
There was a problem hiding this comment.
I think this section should be reorganized. Something like this:
To update release notes:
- <Action. Helping information.>
- <Action. Helping information.>
- <Action. Helping information.>
...
The steps that requires to do something before doing previous step looks counter-user-friendly :)
There was a problem hiding this comment.
I definitely agree that this section is a bit convoluted, but for this PR I would like to just focus on changing the part that this PR touches.
tool/README.md
Outdated
| [README.md](https://github.com/flutter/devtools/blob/master/packages/devtools_app/lib/src/framework/release_notes/README.md) | ||
| for details on where to add DevTools release notes to Flutter website and how to test them. | ||
|
|
||
| 1. The release notes for the clean version can be found in [NEXT_RELEASE_NOTES.md](./release_notes/NEXT_RELEASE_NOTES.md) |
There was a problem hiding this comment.
It is not instruction, but helping information. It should not be item in this list of steps.
There was a problem hiding this comment.
In our case the actual release notes will be copied from that file, they will already be prepared there.
I'll make the instructions clearer here.
| See the release notes | ||
| [README.md](https://github.com/flutter/devtools/blob/master/packages/devtools_app/lib/src/framework/release_notes/README.md) | ||
| for details on where to add DevTools release notes to Flutter website and how to test them. | ||
|
|
There was a problem hiding this comment.
Would it make sense to add header for the list? Like:
To verify and submit release notes:
There was a problem hiding this comment.
I believe that is already the case
| git checkout $DEVTOOLS_NEXT_BRANCH | ||
| git push -u origin $DEVTOOLS_NEXT_BRANCH |
There was a problem hiding this comment.
will we need to merge master here?
There was a problem hiding this comment.
it is already done as part of the script. the branch should be fresh as a daisy :)
There was a problem hiding this comment.
but after we merge the clean branch to master, only then will we be creating a PR for this next branch and merging, so at that point, it would be one commit behind
There was a problem hiding this comment.
the 2nd branch is built off of the first, so I don't think we will have an issue with this.
If it does end up being an issue then I will come back and modify this process or the instructions :)
|
Generally looks pretty good! The one thing we still need to figure out is what our world will look like when the auto-roller is in place, because we don't want the auto-roller to pick up x.y+1.z-dev.0 the day after it picks up our official release branch x.y.z. However, it sounds like we won't have an autoroller set up until well into Q1, so we can iterate on this approach and modify as needed. |
tool/README.md
Outdated
| 2. Follow the release notes | ||
| [README.md](https://github.com/flutter/devtools/blob/master/packages/devtools_app/lib/src/framework/release_notes/README.md) | ||
| to add these DevTools release notes to Flutter website | ||
| - make sure to also follow the instructions to test them. |
There was a problem hiding this comment.
more of a side note out of the scope of this PR, but testing the release notes viewer in DevTools is cumbersome.
|
@kenzieschmoll In regards to auto bumping dev versions, I've put protections in place so that it won't ever try to bump a clean version. (Which should catch the case of us trying to bump before we get a chance to push the next version :D) |
If we maintain a single branch in devtools ('master') that the autoroller rolls from, it will pick up daily what is on our tip of trunk. And in this scenario, we are basically automatically bumping to the next version as soon as we merge the clean release version. So the autoroller may not even pick up the clean release version before we bump to the next dev. We may have to modify our process to either maintain two branches or prevent any version bumps during flutter selection windows. |
This reverts commit 8916fff.
This PR Adds functionality to our github repository for ensuring Release Note process is respected.
That process is Either:
The Following is a demo of the github workflow protections in action:
http://screencast/cast/NTQ0NTg0NzkyOTA2MTM3Nnw3OTdhZDZhMC03Nw
The following is a demo of the specific changes that happened to the update_version.dart script
http://screencast/cast/NTg1MjIzMzUwNjc1MDQ2NHw4M2FmMjdiNS04Yg
Demo showing the user of the new release_helper.sh
https://drive.google.com/file/d/13sSrPkU2CtE5SKRqXuWjxeJe-gL5HeYT/view?usp=sharing&resourcekey=0-EWRmUXVnjNgUaIOBwri1kg