-
-
Notifications
You must be signed in to change notification settings - Fork 3k
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Merge pull request #6482 from ipfs/release-flow
Revamp go-ipfs Release Flow
- Loading branch information
Showing
3 changed files
with
208 additions
and
39 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,33 @@ | ||
| # EARLY TESTERS PROGRAMME | ||
|
|
||
| ## What is it? | ||
|
|
||
| The early testers programme allows members of the community to self-volunteer to help test `go-ipfs` release candidates. While we invite the _entire_ community to help test releases, members of the early testers program are expected to participate directly and actively in every release. | ||
|
|
||
| ## What are the expectations? | ||
|
|
||
| Members of the early tester program are expected to work closely with us to: | ||
|
|
||
| * Provide high quality, actionable feedback. | ||
| * Work directly with us to debug regressions in the release. | ||
| * Help ensure a rock-solid, timely release. | ||
|
|
||
| We will ask early testers to participate at two points in the process: | ||
|
|
||
| * When go-ipfs enters the second release stage (public beta), early testers will be asked to test go-ipfs on non-production infrastructure. This may involve things like: | ||
| - Running integration tests against the release candidate. | ||
| - Running simulations/benchmarks on the release candidate. | ||
| - Manually testing the release candidate to check for regressions. | ||
| * When go-ipfs enters the third release stage (soft release), early testers will be asked to partially deploy the release candidate to production infrastructure. Release candidates at this stage are expected to be identical to the final release. However, this stage allows the go-ipfs team to fix any last-minute regressions without cutting an entirely new release. | ||
|
|
||
| ## Who has signed up? | ||
|
|
||
| - [ ] Infura (@MichaelMure) | ||
| - [ ] Textile (@sanderpick) | ||
| - [ ] Pinata (@obo20) | ||
| - [ ] RTrade (@postables) | ||
| - [ ] QRI (@b5) | ||
|
|
||
| ## How to sign up? | ||
|
|
||
| Simply submit a PR to this document by adding your project name and contact. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,104 @@ | ||
| > Release Issue Template | ||
| # go-ipfs X.Y.Z Release | ||
|
|
||
| We're happy to announce go-ipfs X.Y.Z, bla bla... | ||
|
|
||
| ## 🗺 What's left for release | ||
|
|
||
| <List of items with PRs and/or Issues to be considered for this release> | ||
|
|
||
| ## 🔦 Highlights | ||
|
|
||
| < top highlights for this release notes > | ||
|
|
||
| ## Changelog | ||
|
|
||
| < changelog generated by bin/mkreleaselog > | ||
|
|
||
| ## ✅ Release Checklist | ||
|
|
||
| For each RC published in each stage: | ||
|
|
||
| - version string in `version.go` has been updated | ||
| - tag commit with vX.Y.Z-rcN | ||
| - upload to dist.ipfs.io | ||
| 1. Build: https://github.com/ipfs/distributions#usage. | ||
| 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. | ||
|
|
||
| Checklist: | ||
|
|
||
| - [ ] **Stage 1 - Internal 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) | ||
| - [ ] Network Testing: | ||
| - [ ] test lab things - TBD | ||
| - [ ] Infrastructure Testing: | ||
| - [ ] Deploy new version to a subset of Bootstrappers | ||
| - [ ] Deploy new version to a subset of Gateways | ||
| - [ ] Deploy new version to a subset of Preload nodes | ||
| - [ ] Collect metrics every day. Work with the Infrastructure team to learn of any hiccup | ||
| - [ ] IPFS Application Testing - Run the tests of the following applications: | ||
| - [ ] WebUI | ||
| - [ ] IPFS Desktop | ||
| - [ ] IPFS Companion | ||
| - [ ] NPM on IPFS | ||
| - [ ] **Stage 2 - Public Beta** | ||
| - [ ] 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** | ||
| - [ ] 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 | ||
| - [ ] Ensure that all the examples we have produced for go-ipfs run without problems | ||
| - [ ] Update HTTP-API Documentation on the Website using https://github.com/ipfs/http-api-docs | ||
| - [ ] Invite the IPFS [_early testers_](https://github.com/ipfs/go-ipfs/tree/master/docs/EARLY_TESTERS.md) to deploy the release to part of their production infrastructure. | ||
| - [ ] Invite the wider community through (link to the release issue): | ||
| - [ ] [discuss.ipfs.io](https://discuss.ipfs.io/c/announcements) | ||
| - [ ] IRC | ||
| - [ ] **Stage 4 - Release** | ||
| - [ ] Final preparation | ||
| - [ ] Verify that version string in [`repo/version.go`](https://github.com/ipfs/go-ipfs/tree/master/repo/version.go) has been updated | ||
| - [ ] tag commit with vX.Y.Z | ||
| - [ ] update release branch to point to release commit (`git merge vX.Y.Z`). | ||
| - [ ] Release published | ||
| - [ ] to [dist.ipfs.io](https://dist.ipfs.io) | ||
| - [ ] to [npm-go-ipfs](https://github.com/ipfs/npm-go-ipfs) | ||
| - [ ] to [chocolatey](https://chocolatey.org/packages/ipfs) | ||
| - [ ] to [github](https://github.com/ipfs/go-ipfs/releases) | ||
| - [ ] Publish a Release Blog post (at minimum, a c&p of this release issue with all the highlights, API changes, link to changelog and thank yous) | ||
| - [ ] Broadcasting (link to blog post) | ||
| - [ ] IRC | ||
| - [ ] [Reddit](https://reddit.com/r/ipfs) | ||
| - [ ] [discuss.ipfs.io](https://discuss.ipfs.io/c/announcements) | ||
| - [ ] Announce it on the [IPFS Users Mailing List](https://groups.google.com/forum/#!forum/ipfs-users) | ||
|
|
||
| ## ❤️ Contributors | ||
|
|
||
| < list generated by bin/mkreleaselog > | ||
|
|
||
| Would you like to contribute to the IPFS project and don't know how? Well, there are a few places you can get started: | ||
|
|
||
| - Check the issues with the `help wanted` label in the [go-ipfs repo](https://github.com/ipfs/go-ipfs/issues?q=is%3Aopen+is%3Aissue+label%3A%22help+wanted%22) | ||
| - Join an IPFS All Hands, introduce yourself and let us know where you would like to contribute - https://github.com/ipfs/team-mgmt/#weekly-ipfs-all-hands | ||
| - Hack with IPFS and show us what you made! The All Hands call is also the perfect venue for demos, join in and show us what you built | ||
| - Join the discussion at [discuss.ipfs.io](https://discuss.ipfs.io/) and help users finding their answers. | ||
| - Join the [Go Core Dev Team Weekly Sync](https://github.com/ipfs/team-mgmt/issues/650) and be part of the Sprint action! | ||
|
|
||
| ## ⁉️ Do you have questions? | ||
|
|
||
| The best place to ask your questions about IPFS, how it works and what you can do with it is at [discuss.ipfs.io](http://discuss.ipfs.io). We are also available at the `#ipfs` channel on Freenode, which is also [accessible through our Matrix bridge](https://riot.im/app/#/room/#freenode_#ipfs:matrix.org). | ||
|
|
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,39 +1,71 @@ | ||
| # go-ipfs releases | ||
|
|
||
| ## Release Schedule | ||
| go-ipfs is on a six week release schedule. Following a release, there will be | ||
| five weeks for code of any type (features, bugfixes, etc) to be added. After | ||
| the five weeks is up, a release candidate is tagged and only important bugfixes | ||
| will be allowed up to release day. | ||
|
|
||
| ## Release Candidate Checklist | ||
| - [ ] CHANGELOG.md has been updated | ||
| - use `./bin/mkreleaselog` to generate a nice starter list | ||
| - [ ] version string in `version.go` has been updated | ||
| - [ ] tag commit with vX.Y.Z-rcN | ||
|
|
||
| ## Pre-Release Checklist | ||
| - [ ] before release, tag 'release candidate' for users to test against | ||
| - if bugs are found/fixed, do another release candidate | ||
| - [ ] all tests pass (no exceptions) | ||
| - [ ] run interop tests https://github.com/ipfs/interop#test-with-a-non-yet-released-version-of-go-ipfs | ||
| - [ ] webui works (for most definitions of 'works') - Test the multiple pages and verify that no visible errors are shown. | ||
| - [ ] CHANGELOG.md has been updated | ||
| - use `./bin/mkreleaselog` to generate a nice starter list | ||
| - [ ] version string in `repo/version.go` has been updated | ||
| - [ ] tag commit with vX.Y.Z | ||
| - [ ] update release branch to point to release commit (`git merge vX.Y.Z`). | ||
| - [ ] publish dist.ipfs.io | ||
| - [ ] publish next version to https://github.com/ipfs/npm-go-ipfs | ||
|
|
||
| ## Post-Release | ||
| - [ ] Bump version string in `repo/version.go` to `vX.Y.Z-dev` | ||
| - [ ] Upload the final release to the github releases page: https://github.com/ipfs/go-ipfs/releases | ||
| - Communication | ||
| - [ ] Create the release issue | ||
| - [ ] Announcements (both pre-release and post-release) | ||
| - [ ] IRC | ||
| - [ ] Blog post (at minimum, paste the changelog. optionally add context and thank contributors.) | ||
| - [ ] Update HTTP-API Documentation on the Website using https://github.com/ipfs/http-api-docs | ||
| # `go-ipfs` Release Flow | ||
|
|
||
| ## Table of Contents | ||
|
|
||
| - [Release Philosophy](#release-philosophy) | ||
| - [Release Flow](#release-flow) | ||
| - [Performing a Release](#performing-a-release) | ||
| - [Release Version Numbers (aka semver)](#release-version-numbers-aka-semver) | ||
|
|
||
| ## Release Philosophy | ||
|
|
||
| `go-ipfs` aims to have release every six weeks, two releases per quarter. During these 6 week releases, we go through 4 different stages that gives us the opportunity to test the new version against our test environments (unit, interop, integration), QA in our current production environment, IPFS apps (e.g. Desktop and WebUI) and with our community and _early testers_<sup>[1]</sup> that have IPFS running in production. | ||
|
|
||
| We might expand the six week release schedule in case of: | ||
| - No new updates to be added | ||
| - In case of a large community event that takes the core team availability away (e.g. IPFS Conf, Dev Meetings, IPFS Camp, etc) | ||
|
|
||
| ## 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<sup>[2]</sup> changes during the process, we start over at stage 1. | ||
|
|
||
| ### Stage 1 - Internal Testing | ||
|
|
||
| Before this stage, we expect _all_ tests (interop, testlab, performance, etc.) to pass. | ||
|
|
||
| At this stage, we'll: | ||
| - 1. Start a partial-rollout to our own infrastructure. | ||
| - 2. Test against ipfs and ipfs-shipyard applications. | ||
|
|
||
| **Goal(s):** | ||
| - 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 | ||
|
|
||
| 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 | ||
|
|
||
| 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. | ||
|
|
||
| **Goal(s):** | ||
|
|
||
| 1. Test the release in some production environments with heavy workloads. | ||
| 2. Partially roll-out an upgrade to see how it affects the network. | ||
| 3. Retain the ability to ship last-minute fixes before the final release. | ||
|
|
||
| ### Stage 4 - Release | ||
|
|
||
| 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. | ||
|
|
||
| ## Release Version Numbers (aka semver) | ||
|
|
||
| Until `go-ipfs` 0.4.X, `go-ipfs` was not using semver to communicate the type of release | ||
|
|
||
| Post `go-ipfs` 0.5.X, `go-ipfs` will use semver. This means that patch releases will not contain any breaking changes nor new features. Minor releases might contain breaking changes and always contain some new feature | ||
|
|
||
| Post `go-ipfs` 1.X.X (future), `go-ipfs` will use semver. This means that only major releases will contain breaking changes, minors will be reserved for new features and patches for bug fixes. | ||
|
|
||
| We do not yet retroactively apply fixes to older releases (no Long Term Support releases for now), which means that we always recommend users to update to the latest, whenever possible. | ||
|
|
||
| ---------------------------- | ||
|
|
||
| - <sup>**[1]**</sup> - _early testers_ is an IPFS programme in which members of the community can self-volunteer to help test `go-ipfs` Release Candidates. You find more info about it at [EARLY_TESTERS.md](./EARLY_TESTERS.md) | ||
| - <sup>**[2]**</sup> - A non-trivial change is any change that could potentially introduce an issue not trivially caught by automated testing. This is up to the discretion of the Lead Maintainer but the assumption is that every change is non-trivial unless proven otherwise. |