Skip to content
Permalink

Comparing changes

This is a direct comparison between two commits made in this repository or its related repositories. View the default comparison for this range or learn more about diff comparisons.

Open a pull request

Create a new pull request by comparing changes across two branches. If you need to, you can also . Learn more about diff comparisons here.
base repository: maidsafe/rfcs
Failed to load repositories. Confirm that selected base ref is valid, then try again.
Loading
base: a3231194bcc4a16b142ae3f052e8bb7ad61d6013
Choose a base ref
..
head repository: maidsafe/rfcs
Failed to load repositories. Confirm that selected head ref is valid, then try again.
Loading
compare: 711b1626e22868aee418b750b6e9ac9318cc0055
Choose a head ref
Showing with 15 additions and 29 deletions.
  1. +15 −29 0001-short-term-release-process/0001-release-process-short-term.md
44 changes: 15 additions & 29 deletions 0001-short-term-release-process/0001-release-process-short-term.md
Original file line number Diff line number Diff line change
@@ -24,8 +24,6 @@ for another document.
Uncertainties are indicated using a `*` notation. Rather than have a full `Unresolved Questions`
section at the end, where applicable there is an `Uncertainties` list in each section.

The use of `**` is to denote an idea that came from Shu's diagram/proposal.

## Motivations

So far, we have failed to arrive at a well-defined process for releasing our code. With launch
@@ -50,35 +48,35 @@ Release and deployment for next wave:
Live for users: 2024-07-09 / 825 people / 11 week competition / competition ends: 2024-09-27

Three week development/release cycle:
* Development begins 2024-07-08
* Release candidate branch cut: 2024-07-22
* Development phase begins: 2024-07-08
* Release candidate phase begins: 2024-07-22
* Stable release and production deploy for wave 3: 2024-07-31

### Wave 3

Live for users: 2024-08-01 / 1000 people / 8 week competition / competition ends: 2024-09-27

Three week development/release cycle:
* Development begins 2024-08-01
* Release candidate branch cut: 2024-08-15
* Development phase begins: 2024-08-01
* Release candidate phase begins: 2024-08-15
* Stable release and production deploy for wave 4: 2024-08-22

### Wave 4

Live for users: 2024-08-23 / 1000 people / 5 week competition / competition ends: 2024-09-27

Three week development/release cycle:
* Development begins 2024-08-22
* Release candidate branch cut: 2024-09-05
* Development phase begins: 2024-08-22
* Release candidate phase begins: 2024-09-05
* Stable release and production deploy for wave 5: 2024-09-12

### Wave 5

Live for users: 2024-09-13 / 1000 people / 3 week competition / competition ends: 2024-09-27

Three week development/release cycle:
* Development begins 2024-09-12
* Release candidate branch cut: 2024-09-26
* Development phase begins: 2024-09-12
* Release candidate phase begins: 2024-09-26
* Stable release and production deploy for launch: 2024-10-03

This would perhaps take us to launch. At this point, we could consider setting our crate versions to
@@ -140,13 +138,6 @@ The cycle has the following phases and steps:

We can accommodate hotfixes at any point during the cycle.

#### Uncertainties

* Not completely sure about the duration of each phase. Any opinions?
* We could deploy automatically, but do we need to coordinate with an announcement?
* What does the 'draining' process with two production environments look like? Shu to elaborate on
the details? Do we need this on an environment that we upgrade?

## Release Cycle Anatomy

We'll now elaborate the release cycle described in the last section, discussing each type of release
@@ -159,10 +150,12 @@ crates must use Semantic Versioning. A binary is defined within a crate, and the
it will also have a Semantic Version; however, it is possible to override the `--version` argument
on the binary to provide something custom. Our releases currently produce eight binary artifacts.
It would be useful if we could refer to these collectively with a single version number and package,
where the package name would reflect the version number. ** The `--version` argument would identify
where the package name would reflect the version number. The `--version` argument would identify
this version number, but also identify the individual component using its Semantic Version. *

The proposal is to use `YYYY.MM.X.Y` as the collective version number. **
The proposal is to use `YYYY.MM.X.Y` as the collective version number. The `X` is for the release
cycle and `Y` is a counter from within the release cycle, which will increment if any more RC builds
are made within that cycle.

We would use the collective version number for a single Github Release. The assets for the release
would be the combined binary packages for each platform. The changelog can also be nicely applied to
@@ -171,7 +164,6 @@ this combined release.
#### Uncertainties

* Should Semantic Versions be dropped from user-facing elements?
* What are the `X` and `Y` in the version number?

### Alpha Releases

@@ -220,7 +212,7 @@ record of the existence of the alpha release.
A release candidate (RC) is the binary that's intended to be released as a stable version. The set
of features and fixes in the RC is what's included on `main` in the current cycle, i.e., between now
and the last stable release. After about two weeks of development we should produce the RC for
testing in the staging environment.
testing in the staging environment. Community users will be invited to participate in testing.

An owner should be designated to the process, and it would be useful for this to cycle through
everyone in the team. Once the RC branch is started, we won't accept new features on it, only fixes.
@@ -274,24 +266,18 @@ making a stable release from that branch.
the commit. Any final additions to the changelog can be part of this commit.
* Create a PR for merging the release branch into `stable`.
* Once it's been merged to stable, also merge the release branch into `main`.
* When ready, kick off a workflow for the stable release*. The workflow will:
* When ready, kick off a workflow for the stable release. The workflow will:
- Build the binaries
- Upload them to S3
- Public Github Release
- Publish crates
- Tag based on combined version
* Manually edit the Github Release to apply the latest changelog entry to the description*
* Manually edit the Github Release to apply the latest changelog entry to the description
* Delete the release branch

We would now be in a position to deploy the stable release to the `PROD-01` (and possibly `PROD-02`)
environment. The production deployment would be covered in another RFC.

#### Uncertainties

* Obviously this could be done automatically on push, but we may want to coordinate with an
announcement?
* It's probably possible to automate this, but it's a very low-effort manual step.

## Hotfixes

Hotfixes are intended to quickly fix a severe bug in a stable release. They can occur at any time