From 354dabf3cafa89634057f42d1490fb1b1e3f8963 Mon Sep 17 00:00:00 2001 From: Sebastiaan van Stijn Date: Thu, 4 Feb 2016 23:42:56 +0100 Subject: [PATCH] Release checklist - bump versions earlier Bump both API and VERSION directly after the release branch is created. All changes to master after that are (by default) for the *next* release. Signed-off-by: Sebastiaan van Stijn --- project/RELEASE-CHECKLIST.md | 33 ++++++++++++++++++--------------- 1 file changed, 18 insertions(+), 15 deletions(-) diff --git a/project/RELEASE-CHECKLIST.md b/project/RELEASE-CHECKLIST.md index 159f92f329..2b0e7caae3 100644 --- a/project/RELEASE-CHECKLIST.md +++ b/project/RELEASE-CHECKLIST.md @@ -76,15 +76,25 @@ git cherry-pick ... ``` -### 2. Bump the API version on master +### 2. Update the VERSION files and API version on master -We don't want to stop contributions to master just because we are releasing. At -the same time, now that the release branch exists, we don't want API changes to -go to the now frozen API version. +We don't want to stop contributions to master just because we are releasing. +So, after the release branch is up, we bump the VERSION and API version to mark +the start of the "next" release. -Create a new entry in `docs/reference/api/` by copying the latest and -bumping the version number (in both the file's name and content), and submit -this in a PR against master. +#### 2.1 Update the VERSION files + +Update the content of the `VERSION` file to be the next minor (incrementing Y) +and add the `-dev` suffix. For example, after the release branch for 1.5.0 is +created, the `VERSION` file gets updated to `1.6.0-dev` (as in "1.6.0 in the +making"). + +#### 2.2 Update API version on master + +We don't want API changes to go to the now frozen API version. Create a new +entry in `docs/reference/api/` by copying the latest and bumping the version +number (in both the file's name and content), and submit this in a PR against +master. ### 3. Update CHANGELOG.md @@ -490,14 +500,7 @@ echo "https://github.com/$GITHUBUSER/docker/compare/docker:master...$GITHUBUSER: Again, get two maintainers to validate, then merge, then push that pretty blue button to delete your branch. -### 24. Update the VERSION files - -Now that version X.Y.Z is out, time to start working on the next! Update the -content of the `VERSION` file to be the next minor (incrementing Y) and add the -`-dev` suffix. For example, after 1.5.0 release, the `VERSION` file gets -updated to `1.6.0-dev` (as in "1.6.0 in the making"). - -### 25. Rejoice and Evangelize! +### 24. Rejoice and Evangelize! Congratulations! You're done.