docs: improvements to the release doc
* Adds missing items to ToC * Adds sub-level items to ToC (there's not many, lets allow people to more easily skip to a section) * Moves release process illustration to the top of the release flow section - it's an overview, it should be at the start not the end * Fix a typo * Removes braces in "Goal(s):" where there is clearly more than one
Alan Shaw committed
Aug 30, 2019 at 10:29 UTC
d0983b76414b0e5df7bbd5983a283261157e346e
1 file changed
+23
-11
docs/releases.md
+23
-11
@@ -4,6 +4,13 @@
4
5
- [Release Philosophy](#release-philosophy)
6
- [Release Flow](#release-flow)
7
+ - [Stage 0 - Automated Testing](#stage-0--automated-testing)
8
+ - [Stage 1 - Internal Testing](#stage-1--internal-testing)
9
+ - [Stage 2 - Community Dev Testing](#stage-2--community-dev-testing)
10
+ - [Stage 3 - Community Prod Testing](#stage-2--community-prod-testing)
11
+ - [Stage 4 - Release](#stage-4--release)
12
+- [Release Cycle](#release-cycle)
13
+ - [Patch Releases](#patch-releases)
14
- [Performing a Release](#performing-a-release)
15
- [Release Version Numbers (aka semver)](#release-version-numbers-aka-semver)
16
@@ -12,13 +19,16 @@
19
`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.
20
21
We might expand the six week release schedule in case of:
22
+
23
- 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)
24
+- In case of a large community event that takes the core team availability away (e.g. IPFS Conf, Dev Meetings, IPFS Camp, etc.)
25
26
## Release Flow
27
28
`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<sup>[2]</sup> changes during the process, we start over at stage 0.
29
30
+
31
+
32
### Stage 0 - Automated Testing
33
34
At this stage, we expect _all_ automated tests (interop, testlab, performance, etc.) to pass.
@@ -26,24 +36,28 @@ At this stage, we expect _all_ automated tests (interop, testlab, performance, e
36
### Stage 1 - Internal Testing
37
38
At this stage, we'll:
29
-- 1. Start a partial-rollout to our own infrastructure.
30
-- 2. Test against ipfs and ipfs-shipyard applications.
39
32
-**Goal(s):**
33
-- 1. Make sure we haven't introduced any obvious regressions.
34
-- 2. Test the release in an environment we can monitor and easily roll back (i.e., our own infra).
40
+1. Start a partial-rollout to our own infrastructure.
41
+2. Test against ipfs and ipfs-shipyard applications.
42
+
43
+**Goals:**
44
+
45
+1. Make sure we haven't introduced any obvious regressions.
46
+2. Test the release in an environment we can monitor and easily roll back (i.e. our own infra).
47
48
### Stage 2 - Community Dev Testing
49
50
At this stage, we'll announce the impending release to the community and ask for beta testers.
51
40
-**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.
52
+**Goal:**
53
+
54
+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.
55
56
### Stage 3 - Community Prod Testing
57
44
-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.
58
+At this stage, we consider the release to be "production ready" and will ask the community and our early testers to (partially) deploy the release to their production infrastructure.
59
46
-**Goal(s):**
60
+**Goals:**
61
62
1. Test the release in some production environments with heavy workloads.
63
2. Partially roll-out an upgrade to see how it affects the network.
@@ -53,8 +67,6 @@ At this stage, we consider the release to be "production ready" and ask will ask
67
68
At this stage, the release is "battle hardened" and ready for wide deployment.
69
56
-
57
-
70
## Release Cycle
71
72
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.