Skip to content

Latest commit

 

History

History
113 lines (66 loc) · 6.36 KB

releases.md

File metadata and controls

113 lines (66 loc) · 6.36 KB
Raw

go-ipfs Release Flow

Table of Contents

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[1] 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 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.

go-ipfs-release-process-illustration

Stage 0 - Automated Testing

At this stage, we expect all automated 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.
  2. Test against ipfs and ipfs-shipyard applications.

Goals:

  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 - 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 - Community Prod Testing

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.

Goals:

  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.

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

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:

  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).

Some patch releases, especially ones fixing one or more complex bugs, may undergo the full release process.

Security Fix Policy

Any release may contain security fixes. Unless the fix addresses a bug being exploited in the wild, the fix will not be called out in the release notes. Please make sure to update ASAP.

By policy, the team will usually wait until about 2 weeks after the final release to announce any fixed security issues. However, depending on the impact and ease of discovery of the issue, the team may wait more or less time. It is important to always update to the latest version ASAP and file issues if you're unable to update for some reason.

Finally, unless a security issue is actively being exploited or a significant number of users are unable to update to the latest version (e.g., due to a difficult migration, breaking changes, etc.), security fixes will not be backported to previous releases.

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 not more than 48 hours after the previous release.

This issue is pinned and labeled "release". When the cycle is due to begin the 5 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.

  • [1] - 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
  • [2] - 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.