From bb8944ab1738c11143d14d62c86146e0062e4a5b Mon Sep 17 00:00:00 2001 From: Mike Hearn Date: Wed, 25 May 2016 11:52:16 +0200 Subject: [PATCH] Docsite: more info on how to cut a release. In future this will get more complicated as we make the code know its own version, etc. But for now it'll do. --- docs/source/release-process.rst | 21 ++++++++++++++++++++- 1 file changed, 20 insertions(+), 1 deletion(-) diff --git a/docs/source/release-process.rst b/docs/source/release-process.rst index 46768f32cf..7116ba0b09 100644 --- a/docs/source/release-process.rst +++ b/docs/source/release-process.rst @@ -20,4 +20,23 @@ forever and the software will be considered production ready. Until then, expect hard hat. Our goal is to cut a new milestone roughly once a month. There are no fixed dates. If need be, a milestone may slip by -a few days to ensure the code is sufficiently usable. \ No newline at end of file +a few days to ensure the code is sufficiently usable. Usually the release will happen around the end of the month. + +Steps to cut a release +====================== + +1. Pick a commit that is stable and do basic QA: run all the tests, run the demos. +2. Review the commits between this release and the last looking for new features, API changes, etc. Make sure the + summary in the current section of the :doc:`release-notes` is correct and update if not. Then move it into the right + section for this release. This is the right place to put any advice on how to port app code from the last release. +3. Additionally, if there are any new features or APIs that deserve a new section in the docsite and the author didn't + create one, bug them to do so a day or two before the release. +4. Regenerate the docsite if necessary and commit. +5. Create a branch with a name like `release-M0` where 0 is replaced by the number of the milestone. +6. Tag that branch with a tag like `release-M0.0` +7. Push the branch and the tag to git. +8. Write up a short announcement containing the summary of new features, changes, and API breaks. Send it to the + r3dlg-awg mailing list. + +If there are serious bugs found in the release, backport the fix to the branch and then tag it with e.g. `release-M0.1` +Minor changes to the branch don't have to be announced unless it'd be critical to get all developers updated. \ No newline at end of file