Skip to content
This repository has been archived by the owner on Feb 12, 2024. It is now read-only.

Latest commit

 

History

History
112 lines (66 loc) · 6.33 KB

RELEASES.md

File metadata and controls

112 lines (66 loc) · 6.33 KB
Raw

Releases

Table of Contents

Release Philosophy

js-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

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

js-ipfs release flow cartoon

Stage 0 - Automated Testing

At this stage, we expect all automated tests (unit, functional, integration, 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 applications in the ipfs and ipfs-shipyard organisations and a selection of other hand picked projects.

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 pre-release 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. A new version is published to npm, announcements are made and a blog post is published to blog.ipfs.io.

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.

Performing a Release

The release is managed by the "Lead Maintainer" for js-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

js-ipfs is currently pre-1.0. In semver terms this means anything may change at any time.

However, pre-1.0 js-ipfs reserves MINOR version increments for BREAKING CHANGES and feature additions and PATCH version increments for bug fixes.

Post 1.x.x (future), MAJOR version number increments will contain BREAKING CHANGES, MINOR version increments will be reserved for backwards compatible new features and PATCH version increments 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.

Release Candidates

Every commit to master results in the publishing of a Release Candidate. These are made available for users who want to try out the "bleeding edge" and can be installed using version numbers with the form x.y.z-rc.n where x, y, and z are the usual MAJOR, MINOR and PATCH version numbers and n (starting at 0) which is the number of commits to master since the last full release.

Alternatively the latest RC is tagged next on npm and can be installed using npm install ipfs@next.

  • [1] - early testers is an IPFS programme in which members of the community can self-volunteer to help test js-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 that could not categorically be 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.