docs(releasing): document the LH Release Process #4201
Conversation
|
Of note, I'm proposing we don't rotate but just use a brendan>paul>patrick cascade for now. Also, this includes a ~bi-weekly (aka twice monthly) release cadence. |
docs/releasing.md
Outdated
| ### Release publicity | ||
|
|
||
| 1. Release mgr copies changelog to a new [Releases](https://github.com/GoogleChrome/lighthouse/releases). Tags and ships it. | ||
| 1. Release mgr adds Release notes to the repo's [changelog](https://github.com/GoogleChrome/lighthouse/blob/master/changelog.md). |
There was a problem hiding this comment.
do we intend to split this out from the PR with the version bumps? maybe worth noting to do it in the same if not :)
There was a problem hiding this comment.
oops. left this line in by mistake.
no changelog is done with that PR. and then reused here.
| 1. Release mgr copies changelog to a new [Releases](https://github.com/GoogleChrome/lighthouse/releases). Tags and ships it. | ||
| 1. Release mgr tells the _LH public_ Hangout chat about the new version. | ||
| 1. V writes and publishes the [/updates](https://developers.google.com/web/updates/) blog post | ||
| 1. Paul writes the tweet and sends it on [@____lighthouse](https://twitter.com/____lighthouse). |
There was a problem hiding this comment.
Question: do we want to wait for the /updates post to be live before Tweeting it out or just stick to the release notes?
There was a problem hiding this comment.
waiting for /updates seems better. those are more digestible.
anyone watching the github repo gets an email for a new Release anyway.
There was a problem hiding this comment.
SGTM. Can we say "writes the tweet with the /updates post"
|
|
||
| 1. Release mgr copies changelog to a new [Releases](https://github.com/GoogleChrome/lighthouse/releases). Tags and ships it. | ||
| 1. Release mgr tells the _LH public_ Hangout chat about the new version. | ||
| 1. V writes and publishes the [/updates](https://developers.google.com/web/updates/) blog post |
|
|
||
| ### Cadence | ||
|
|
||
| We ship twice a month, on the Thursday before the 15th and the Thursday before 1st. These dates are added to the internal Lighthouse calendar. |
There was a problem hiding this comment.
Why twice a month? My understanding was that we usually ship a big release once a month, and if needed ship a smaller release the second time around.
There was a problem hiding this comment.
I'm open to that. Seems okay for us to be more conservative and make for larger releases.
ok how about
We ship once a month, on the Thursday before the 1st. While not necessary, followup minor/patch releases may be done if warranted.
cc @vinamratasingal @patrickhulce
|
|
||
| ### Cadence | ||
|
|
||
| We ship twice a month, on the Thursday before the 15th and the Thursday before 1st. These dates are added to the internal Lighthouse calendar. |
There was a problem hiding this comment.
Also- it would be helpful to have something in here about how we choose to number our releases (i.e. why 2.7 vs 2.7.1)
There was a problem hiding this comment.
it's in there. see Versioning
|
|
||
| ### Release manager | ||
|
|
||
| Rather than a rotation, release manager is appointed. However if the appointed manager is absent, the next engineer in the following list owns it: |
There was a problem hiding this comment.
Who appoints the release manager?
There was a problem hiding this comment.
I'm proposing it's basically brendan, then me, then patrick, based on availability.
There was a problem hiding this comment.
Got it. Not sure if I grokked that from the text, suggested revision: "release manager is appointed, according to the list below. However, if the appointed manager is absent, the next engineer in line in the list would own it."
|
|
||
| ### Release publicity | ||
|
|
||
| 1. Release mgr copies changelog to a new [Releases](https://github.com/GoogleChrome/lighthouse/releases). Tags and ships it. |
There was a problem hiding this comment.
Also- when we writeup the release log- can we make sure to mention when the release will land in DT?
There was a problem hiding this comment.
good idea. we can say "We expect this release to ship in the DevTools of Chrome XX" though we can't necessarily promise.
There was a problem hiding this comment.
Yup yup- just to give folks an idea. If we can add that in to this doc, that would be great.
fixes #3579