@cryptotaxi247 / kubo / commits / 6751f714b

docs: update Release Flow

David Dias committed Jul 3, 2019 at 09:23 UTC 6751f714baf4f19e7ebe449402a9b2491eaa6ef1
1 file changed +150 -32
docs/releases.md
+150 -32
@@ -1,39 +1,157 @@
1 -# go-ipfs releases
1 +# `go-ipfs` Release Flow
2
3 -## Release Schedule
4 -go-ipfs is on a six week release schedule. Following a release, there will be
5 -five weeks for code of any type (features, bugfixes, etc) to be added. After
6 -the five weeks is up, a release candidate is tagged and only important bugfixes
7 -will be allowed up to release day.
3 +## Table of Contents
4
9 -## Release Candidate Checklist
10 -- [ ] CHANGELOG.md has been updated
11 - - use `./bin/mkreleaselog` to generate a nice starter list
5 +- [Release Philosophy](#release-philosophy)
6 +- [Release Flow](#release-flow)
7 +- [Performing a Release](#performing-a-release)
8 +- [Release Version Numbers (aka semver)](#release-version-numbers-aka-semver)
9 +
10 +## Release Philosophy
11 +
12 +`go-ipfs` aims to have release every six weeks, two releases per quarter. During these 6 week releases, we go through 4 different stages of Release Candidates (RC) that gives us the opportunity to test the new version against our test envinronments, production envinronments, IPFS apps (e.g. Desktop and WebUI) and with our close partners that have IPFS running in Production, by leveraging their own test infrastructure.
13 +
14 +We might expand the six week release schedule in case of:
15 +- No new updates to be added
16 +- In case of a large community event that takes the core team availability away (e.g. IPFS Conf, Dev Meetings, IPFS Camp, etc)
17 +
18 +## Release Flow
19 +
20 +`go-ipfs` releases come in 4 stages:
21 +
22 +- **Release Stage 1 - Internal testing** - Test the Release against our testing infrastructure, including interoperability, integration, test lab, multiple runtimes and the apps we've built (WebUI, Desktop, NPM on IPFS, HTTP Client Libraries). The intent is to make this stage fully automated (and somewhat is already), until then, we manually check a list and ensure that all tests have been run
23 +- **Release Stage 2 - Invite IPFS partners to test** - Reach out to our partners (i.e. projects that have volunteered to support `go-ipfs` by using their own test infrastructure and tell us the results)
24 +- **Release Stage 3 - Announce to the broader community** - Communicate to the community that a new Release Candidate is ready and that everyone is welcome to test it with us
25 +- **Release Stage 4 - Complete the Release** - Finalize the release, start the next release.
26 +
27 +The Release Stages are not linked to Release Candidate numbers, in fact, there can be multiple release candidate per stages as we catch bugs and improve the release itself.
28 +
29 +<p align="center">
30 + <a href="https://ipfs.io">
31 + <img src="https://gateway.ipfs.io/ipfs/QmaFtLxoCAm5vFQ9AftKkhJwSAdDdF1jzV9DfzW6gbXqFL/Paper.Sketches.23.png" width="450" />
32 + </a>
33 +</p>
34 +
35 +## Performing a Release
36 +
37 +The first step is for the `Lead Maintainer` for `go-ipfs` to open an issue with Title `go-ipfs <version> Release` and a c&p of the following template:
38 +
39 +```
40 +> <short tl;dr; of the release>
41 +
42 +# 🗺 What's left for release
43 +
44 +<List of items with PRs and/or Issues to be considered for this release>
45 +
46 +# 🔦 Highlights
47 +
48 +<List of items with PRs and/or Issues to be considered for this release>
49 +
50 +# 🏗 API Changes
51 +
52 +<List of API changes, if any>
53 +
54 +# ✅ Release Checklist
55 +
56 +For each RC published in each stage:
57 - [ ] version string in `version.go` has been updated
58 - [ ] tag commit with vX.Y.Z-rcN
59
15 -## Pre-Release Checklist
16 -- [ ] before release, tag 'release candidate' for users to test against
17 - - if bugs are found/fixed, do another release candidate
18 -- [ ] all tests pass (no exceptions)
19 -- [ ] run interop tests https://github.com/ipfs/interop#test-with-a-non-yet-released-version-of-go-ipfs
20 -- [ ] webui works (for most definitions of 'works') - Test the multiple pages and verify that no visible errors are shown.
60 +### Release Stage 1 - Internal testing
61 +
62 +When Release Stage 1, there is a features freeze for the release branch.
63 +
64 - [ ] CHANGELOG.md has been updated
65 - use `./bin/mkreleaselog` to generate a nice starter list
23 -- [ ] version string in `repo/version.go` has been updated
24 -- [ ] tag commit with vX.Y.Z
25 -- [ ] update release branch to point to release commit (`git merge vX.Y.Z`).
26 -- [ ] publish dist.ipfs.io
27 -- [ ] publish next version to https://github.com/ipfs/npm-go-ipfs
28 -
29 -## Post-Release
30 -- [ ] Bump version string in `repo/version.go` to `vX.Y.Z-dev`
31 -- [ ] Upload the final release to the github releases page: https://github.com/ipfs/go-ipfs/releases
32 -- Communication
33 - - [ ] Create the release issue
34 - - [ ] Announcements (both pre-release and post-release)
35 - - [ ] Twitter
36 - - [ ] IRC
37 - - [ ] Reddit
38 - - [ ] Blog post (at minimum, paste the changelog. optionally add context and thank contributors.)
39 -- [ ] Update HTTP-API Documentation on the Website using https://github.com/ipfs/http-api-docs
66 +- [ ] Automated Testing - Ensure that all tests are passing, this includes:
67 + - [ ] unit
68 + - [ ] sharness
69 + - [ ] [interop](https://github.com/ipfs/interop#test-with-a-non-yet-released-version-of-go-ipfs)
70 +- [ ] Network Testing:
71 + - [ ] test lab things
72 +- [ ] Infrastructure Testing:
73 + - [ ] Deploy new version to a subset of Bootstrappers
74 + - [ ] Deploy new version to a subset of Gateways
75 + - [ ] Deploy new version to a subset of Preload nodes
76 + - [ ] Collect metrics every day. Work with the Infrastructure team to learn of any hiccup
77 +- [ ] IPFS HTTP Client Libraries Testing:
78 + - [ ] [JS](http://github.com/ipfs/js-ipfs-http-client)
79 + - [ ] [Go](https://github.com/ipfs/go-ipfs-api)
80 +- [ ] IPFS Application Testing - Run the tests of the following applications:
81 + - [ ] WebUI
82 + - [ ] IPFS Desktop
83 + - [ ] IPFS Companion
84 + - [ ] NPM on IPFS
85 +
86 +### Release Stage 2 - Invite IPFS partners to test
87 +
88 +- [ ] Reach out to the following IPFS partners for testing this release (check when no more problems have been reported):
89 + - [ ] Infura
90 + - [ ] Textila
91 + - [ ] Open Bazaar
92 + - [ ] QRI
93 +- [ ] Run tests available in the following repos with the latest RC (check when all tests pass):
94 + - [ ] [orbit-db](https://github.com/orbitdb/orbit-db)
95 +
96 +PSA: If you are a heavy user of `go-ipfs`, have developed a solid test infrastructure for your application and would love to help us would like to help us test `go-ipfs` release candidates, reach out to go-ipfs-wg@ipfs.io.
97 +
98 +### Release Stage 3 - Announce to the broader community
99 +
100 +- [ ] Documentation
101 + - [ ] Ensure that CHANGELOG.md is up to date
102 + - [ ] Ensure that README.md is up to date
103 + - [ ] Ensure that all the examples we have produced for go-ipfs run without problems
104 + - [ ] Update HTTP-API Documentation on the Website using https://github.com/ipfs/http-api-docs
105 +- [ ] Invite the community through (link to the release issue):
106 + - [ ] [discuss.ipfs.io](https://discuss.ipfs.io/c/announcements)
107 + - [ ] Twitter
108 +
109 +### Release Stage 4 - Complete the Release
110 +
111 +- Take a snapshot between of everyone that has contributed to this release (including its subdeps in IPFS, libp2p, IPLD and multiformats) using [`name-your-contributors`](https://www.npmjs.com/package/name-your-contributors). Generate a nice markdown list with [this script](https://gist.github.com/alanshaw/5a2d9465c5a05b201d949551bdb1fcc3). Add it to this issue.
112 +
113 +- [ ] Final preparation
114 + - [ ] Verify that version string in `repo/version.go` has been updated
115 + - [ ] tag commit with vX.Y.Z
116 + - [ ] update release branch to point to release commit (`git merge vX.Y.Z`).
117 + - [ ] publish dist.ipfs.io
118 + - [ ] publish next version to https://github.com/ipfs/npm-go-ipfs
119 +- [ ] 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)
120 +- [ ] Broadcasting (link to blog post)
121 + - [ ] Twitter
122 + - [ ] IRC
123 + - [ ] Reddit
124 + - [ ] [discuss.ipfs.io](https://discuss.ipfs.io/c/announcements)
125 + - [ ] Announce it on the [IPFS Users mlist](https://groups.google.com/forum/#!forum/ipfs-users)
126 +
127 +# ❤️ Huge thank you to everyone that made this release possible
128 +
129 +In alphabetical order, here are all the humans that contributed to the release:
130 +
131 +- <use script -- listed in Release Stage 4 -- to generate a list of everyone that contributed for this release>
132 +
133 +# 🙌🏽 Want to contribute?
134 +
135 +Would you like to contribute to the IPFS project and don't know how? Well, there are a few places you can get started:
136 +
137 +- 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)
138 +- 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
139 +- 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
140 +- Join the discussion at http://discuss.ipfs.io/ and help users finding their answers.
141 +- Join the [Go Core Dev Team Weekly Sync](https://github.com/ipfs/team-mgmt/issues/650) and be part of the Sprint action!
142 +
143 +# ⁉️ Do you have questions?
144 +
145 +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.
146 +```
147 +
148 +## Release Version Numbers (aka semver)
149 +
150 +Until `go-ipfs` 0.4.X, `go-ipfs` was not using semver to communicate the type of relase
151 +
152 +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
153 +
154 +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.
155 +
156 +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.
157 +TBW