From d433d7c9ac32cb65376d6d09f5e359f255ecca81 Mon Sep 17 00:00:00 2001 From: Steven Allen Date: Fri, 2 Aug 2019 10:45:23 -0700 Subject: [PATCH 1/7] feat: add stage 0 We do automated testing before we test on infra, etc. Make that explicit. --- docs/RELEASE_ISSUE_TEMPLATE.md | 11 ++++++----- docs/releases.md | 14 ++++++++------ 2 files changed, 14 insertions(+), 11 deletions(-) diff --git a/docs/RELEASE_ISSUE_TEMPLATE.md b/docs/RELEASE_ISSUE_TEMPLATE.md index 7bb2bbc6681..c7b53f920d0 100644 --- a/docs/RELEASE_ISSUE_TEMPLATE.md +++ b/docs/RELEASE_ISSUE_TEMPLATE.md @@ -30,16 +30,17 @@ For each RC published in each stage: Checklist: -- [ ] **Stage 1 - Internal Testing** +- [ ] **Stage 0 - Automated Testing** - [ ] Feature freeze. If any "non-trivial" changes (see the footnotes of [docs/releases.md](https://github.com/ipfs/go-ipfs/tree/master/docs/releases.md) for a definition) get added to the release, uncheck all the checkboxes and return to this stage. - - [ ] CHANGELOG.md has been updated - - use [`./bin/mkreleaselog`](https://github.com/ipfs/go-ipfs/tree/master/bin/mkreleaselog) to generate a nice starter list - [ ] Automated Testing (already tested in CI) - Ensure that all tests are passing, this includes: - [ ] unit, sharness, cross-build, etc (`make test`) - [ ] lint (`make test_go_lint`) - [ ] [interop](https://github.com/ipfs/interop#test-with-a-non-yet-released-version-of-go-ipfs) - [ ] [go-ipfs-api](https://github.com/ipfs/go-ipfs-api) - [ ] [go-ipfs-http-client](https://github.com/ipfs/go-ipfs-http-client) +- [ ] **Stage 1 - Internal Testing** + - [ ] CHANGELOG.md has been updated + - use [`./bin/mkreleaselog`](https://github.com/ipfs/go-ipfs/tree/master/bin/mkreleaselog) to generate a nice starter list - [ ] Network Testing: - [ ] test lab things - TBD - [ ] Infrastructure Testing: @@ -52,12 +53,12 @@ Checklist: - [ ] [IPFS Desktop](https://github.com/ipfs-shipyard/ipfs-desktop) - @hacdias - [ ] [IPFS Companion](https://github.com/ipfs-shipyard/ipfs-companion) - @lidel - [ ] [NPM on IPFS](https://github.com/ipfs-shipyard/npm-on-ipfs) - @achingbrain -- [ ] **Stage 2 - Public Beta** +- [ ] **Stage 2 - Community Dev Testing** - [ ] Reach out to the IPFS _early testers_ listed in [docs/EARLY_TESTERS.md](https://github.com/ipfs/go-ipfs/tree/master/docs/EARLY_TESTERS.md) for testing this release (check when no more problems have been reported). If you'd like to be added to this list, please file a PR. - [ ] Reach out to on IRC for beta testers. - [ ] Run tests available in the following repos with the latest beta (check when all tests pass): - [ ] [orbit-db](https://github.com/orbitdb/orbit-db) -- [ ] **Stage 3 - Soft Release** +- [ ] **Stage 3 - Community Prod Testing** - [ ] Documentation - [ ] Ensure that [CHANGELOG.md](https://github.com/ipfs/go-ipfs/tree/master/CHANGELOG.md) is up to date - [ ] Ensure that [README.md](https://github.com/ipfs/go-ipfs/tree/master/README.md) is up to date diff --git a/docs/releases.md b/docs/releases.md index 838d26df467..a964142aba3 100644 --- a/docs/releases.md +++ b/docs/releases.md @@ -17,11 +17,13 @@ We might expand the six week release schedule in case of: ## Release Flow -`go-ipfs` releases come in 4 stages designed to gradually roll out changes and reduce the impact of any regressions that may have been introduced. If we need to merge non-trivial[2] changes during the process, we start over at stage 1. +`go-ipfs` releases come in 5 stages designed to gradually roll out changes and reduce the impact of any regressions that may have been introduced. If we need to merge non-trivial[2] changes during the process, we start over at stage 0. -### Stage 1 - Internal Testing +### Stage 0 - Automated Testing + +At this stage, we expect _all_ automated tests (interop, testlab, performance, etc.) to pass. -Before this stage, we expect _all_ tests (interop, testlab, performance, etc.) to pass. +### Stage 1 - Internal Testing At this stage, we'll: - 1. Start a partial-rollout to our own infrastructure. @@ -31,13 +33,13 @@ At this stage, we'll: - 1. Make sure we haven't introduced any obvious regressions. - 2. Test the release in an environment we can monitor and easily roll back (i.e., our own infra). -### Stage 2 - Public Beta +### Stage 2 - Community Dev Testing At this stage, we'll announce the impending release to the community and ask for beta testers. **Goal:** Test the release in as many non-production environments as possible. This is relatively low-risk but gives us a _breadth_ of testing internal testing can't. -### Stage 3 - Soft Release +### Stage 3 - Community Prod Testing At this stage, we consider the release to be "production ready" and ask will ask the community and our early testers to (partially) deploy the release to their production infrastructure. @@ -53,7 +55,7 @@ At this stage, the release is "battle hardened" and ready for wide deployment. ## Performing a Release -The release is managed by the `Lead Maintainer` for `go-ipfs`. It starts with the opening of an issue containing the content available on the [RELEASE_ISSUE_TEMPLATE](./RELEASE_ISSUE_TEMPLATE.md). Then, the 4 stages will be followed until the release is done. +The release is managed by the `Lead Maintainer` for `go-ipfs`. It starts with the opening of an issue containing the content available on the [RELEASE_ISSUE_TEMPLATE](./RELEASE_ISSUE_TEMPLATE.md). Then, the 5 stages will be followed until the release is done. ## Release Version Numbers (aka semver) From 051d7d839dd9c0f0e742498ce1489f42cb5c260f Mon Sep 17 00:00:00 2001 From: Steven Allen Date: Fri, 2 Aug 2019 10:59:26 -0700 Subject: [PATCH 2/7] doc: add release cycle & patch release process --- docs/releases.md | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/docs/releases.md b/docs/releases.md index a964142aba3..f9fe0ddfdfe 100644 --- a/docs/releases.md +++ b/docs/releases.md @@ -53,6 +53,20 @@ At this stage, we consider the release to be "production ready" and ask will ask At this stage, the release is "battle hardened" and ready for wide deployment. +## Release Cycle + +A full release process should take about 3 weeks, a week per stage 1-3. We will start a new process every 6 weeks, regardless of when the previous release landed unless it's still ongoing. + +## Patch Releases + +Patch releases will usually follow a compressed release cycle and should take 2-3 days. In a patch release: + +1. Internal testing will be compressed to a few hours to a day. +2. Stage 2 will be skipped. +3. Community production testing will be shortened to 1-2 days of opt-in testing in production (early testers can choose to pass). + +Some patch releases, especially ones fixing one or more complex bugs, may undergo the full release process. + ## Performing a Release The release is managed by the `Lead Maintainer` for `go-ipfs`. It starts with the opening of an issue containing the content available on the [RELEASE_ISSUE_TEMPLATE](./RELEASE_ISSUE_TEMPLATE.md). Then, the 5 stages will be followed until the release is done. From 87bda982f1ddb34847c2fdfef191197f118c7aad Mon Sep 17 00:00:00 2001 From: Steven Allen Date: Fri, 2 Aug 2019 11:47:21 -0700 Subject: [PATCH 3/7] doc: fixup some release process wording Co-Authored-By: MollyM --- docs/releases.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/releases.md b/docs/releases.md index f9fe0ddfdfe..cf758791097 100644 --- a/docs/releases.md +++ b/docs/releases.md @@ -61,7 +61,7 @@ A full release process should take about 3 weeks, a week per stage 1-3. We will Patch releases will usually follow a compressed release cycle and should take 2-3 days. In a patch release: -1. Internal testing will be compressed to a few hours to a day. +1. Internal testing will be compressed into a few hours - ideally less than a day. 2. Stage 2 will be skipped. 3. Community production testing will be shortened to 1-2 days of opt-in testing in production (early testers can choose to pass). From 1ec8abeb5922ae67f3b22f12f852cdb20e7c3d52 Mon Sep 17 00:00:00 2001 From: Steven Allen Date: Fri, 2 Aug 2019 12:56:43 -0700 Subject: [PATCH 4/7] doc: improve patch release documentation --- docs/releases.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/docs/releases.md b/docs/releases.md index cf758791097..0e6f6e8a42e 100644 --- a/docs/releases.md +++ b/docs/releases.md @@ -57,7 +57,9 @@ At this stage, the release is "battle hardened" and ready for wide deployment. A full release process should take about 3 weeks, a week per stage 1-3. We will start a new process every 6 weeks, regardless of when the previous release landed unless it's still ongoing. -## Patch Releases +### Patch Releases + +If we encounter a serious bug in the stable latest release, we will create a patch release based on this release. For now, bug fixes will _not_ be backported to previous releases. Patch releases will usually follow a compressed release cycle and should take 2-3 days. In a patch release: From 3f91ee522ff1b218e5d08269605e38cfb4548462 Mon Sep 17 00:00:00 2001 From: Steven Allen Date: Fri, 2 Aug 2019 13:10:49 -0700 Subject: [PATCH 5/7] doc: add release tag --- docs/releases.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/releases.md b/docs/releases.md index 0e6f6e8a42e..3d299a59608 100644 --- a/docs/releases.md +++ b/docs/releases.md @@ -71,7 +71,7 @@ Some patch releases, especially ones fixing one or more complex bugs, may underg ## Performing a Release -The release is managed by the `Lead Maintainer` for `go-ipfs`. It starts with the opening of an issue containing the content available on the [RELEASE_ISSUE_TEMPLATE](./RELEASE_ISSUE_TEMPLATE.md). Then, the 5 stages will be followed until the release is done. +The release is managed by the `Lead Maintainer` for `go-ipfs`. It starts with the opening of an issue containing the content available on the [RELEASE_ISSUE_TEMPLATE](./RELEASE_ISSUE_TEMPLATE.md). This issue will be pinned and labeled with the ["release"](https://github.com/ipfs/go-ipfs/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+label%3Arelease) tag. Then, the 5 stages will be followed until the release is done. ## Release Version Numbers (aka semver) From 8f8a3857cc3ebed4fea524e2efcba8f76e046dc0 Mon Sep 17 00:00:00 2001 From: Steven Allen Date: Fri, 2 Aug 2019 13:11:05 -0700 Subject: [PATCH 6/7] doc: make uploading to github a part of the pre-release process --- docs/RELEASE_ISSUE_TEMPLATE.md | 1 + 1 file changed, 1 insertion(+) diff --git a/docs/RELEASE_ISSUE_TEMPLATE.md b/docs/RELEASE_ISSUE_TEMPLATE.md index c7b53f920d0..3bd414cf902 100644 --- a/docs/RELEASE_ISSUE_TEMPLATE.md +++ b/docs/RELEASE_ISSUE_TEMPLATE.md @@ -27,6 +27,7 @@ For each RC published in each stage: 2. Pin the resulting release. 3. Make a PR against ipfs/distributions with the updated versions, including the new hash in the PR comment. 4. Ask the infra team to update the DNSLink record for dist.ipfs.io to point to the new distribution. +- cut a pre-release on [github](https://github.com/ipfs/go-ipfs/releases) and upload the result of the ipfs/distributions build in the previous step. Checklist: From d6abfb8016e0478d807a219786f040a03fbbad07 Mon Sep 17 00:00:00 2001 From: Steven Allen Date: Mon, 5 Aug 2019 05:21:56 -0700 Subject: [PATCH 7/7] doc: include stage 0 in patch release process. Co-Authored-By: Alan Shaw --- docs/releases.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/releases.md b/docs/releases.md index 3d299a59608..bed145942cd 100644 --- a/docs/releases.md +++ b/docs/releases.md @@ -63,7 +63,7 @@ If we encounter a serious bug in the stable latest release, we will create a pat Patch releases will usually follow a compressed release cycle and should take 2-3 days. In a patch release: -1. Internal testing will be compressed into a few hours - ideally less than a day. +1. Automated and internal testing (stage 0 and 1) will be compressed into a few hours - ideally less than a day. 2. Stage 2 will be skipped. 3. Community production testing will be shortened to 1-2 days of opt-in testing in production (early testers can choose to pass).