Awesome

Release Registry

Single source of truth regarding past and future releases of the Polkadot SDK.

This repo contains a releases-v1.json file that tracks all SDK releases and a JSON schema to ensure that it is in canonical format.

Calendar

Dates with ~ are estimates.

Subscribe

Subscribe to the calendar by adding this iCal link to your Google or Apple calendar:

https://raw.githubusercontent.com/paritytech/release-registry/main/releases-v1.ics

Google has an "From URL" and Apple "New Calendar Subscription" option for this:

Google	Apple

Schedule

Releases

The Polkadot SDK has a stableYYMMDD release every 3 months. Each stable release is supported for one year through a monthly patching schedule. The releases are not exactly 3 months apart, but we try to keep it close. The exact dates are in the calendar.
Stable releases undergo a 1.5 month QA period before being published. This explains the difference between the cutoff and published dates.

Patches

The patching schedule of each stable release is assigned a week of the month. This works well, since there can be at most four stable releases maintained at once. For example: release stable2407 is always patched in the first week of a month. This means that on the first Monday of each month, a new patch is cut off, and on the first Thursday after that Monday, it is published.

Goals

The two main goals of this repo are to improve:

• Communication: clear information about past and upcoming releases. Hoarding information inside Parity is not helpful. This repo aims to make it easier for the Polkadot Ecosystem to know what's going on. This can be helpful to all departments; developers, marketing, devops, security etc.
• Expectations: set clear expectations by having a public schedule. Know when what is coming.

Maintenance

Release Planning

(how to add a new release to the json)

First, check the calendar when about 3 months passed from the publish date of the last release. Then subtract about 1.5 months from that and call the plan command with that date:

python3 scripts/manage.py release plan stable2412 2024-11-06

Then figure out when the first patch date should be; you have to select a Monday for the patching schedule to be calculated (errors if not a Monday). You should select either a week that is empty and has no schedule, or the one where the oldest release is currently being patched.
The script will then count the how many-th monday of the month it is and begin lining it up with the months like in the image above.

Example where we want the first patch to be cut off on 24024-07-29:

python3 scripts/manage.py backfill-patches stable2407 --start-date 2024-07-29

Then update the README to see the changes by running just.

Release Cutoff / Publish

Run this command to cut off a release:

python3 scripts/manage.py release cutoff stable2407-2 2024-09-02

With publish likewise.

Automation

Two scripts are currently in place to:

• manage.py - manage the releases json file (plan, cutoff, publish, etc)
• update-readme.py - updates the README.md file with the data from the releases.json file
• update-calendar.py - generates an iCal file from the releases.json file
• update-badges.py - re-generate the badges in the badges folder for downstream use.

Roadmap

• Double check dates and make the repo public
• Sync with other teams on how to incooperate this
  • Release Engineering
  • Security
  • DevOps
  • Marketing
  • CEX Comms
  • Fellowship Secretary
• Setup Gh pages with calendar
• Setup automation to keep data in sync
• Setup feed to subscribe on changes