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.
Version | Cutoff | Published | End of Life | State |
---|---|---|---|---|
stable2407 | 2024-04-29 | 2024-04-29 | 2025-04-29 | Released |
stable2407-1 | 2024-08-14 | 2024-08-15 | Released | |
stable2407-2 | 2024-08-28 | 2024-09-02 | Released | |
stable2407-3 | 2024-10-10 | 2024-10-10 | Released | |
stable2407-4 | 2024-11-11 | 2024-11-11 | Released | |
stable2407-5 | ~2024-12-02 | ~2024-12-05 | Planned | |
stable2407-6 | ~2025-01-06 | ~2025-01-09 | Planned | |
stable2407-7 | ~2025-02-03 | ~2025-02-06 | Planned | |
(3 more) | ||||
stable2409 | 2024-09-02 | 2024-09-26 | ~2025-09-25 | Released |
stable2409-1 | 2024-10-21 | 2024-10-21 | Released | |
stable2409-2 | 2024-11-14 | 2024-11-14 | Released | |
stable2409-3 | ~2024-12-09 | ~2024-12-12 | Planned | |
stable2409-4 | ~2025-01-13 | ~2025-01-16 | Planned | |
stable2409-5 | ~2025-02-10 | ~2025-02-13 | Planned | |
(8 more) | ||||
stable2412 | ~2024-11-06 | ~2024-12-16 | ~2025-12-16 | Planned |
stable2412-1 | ~2025-01-20 | ~2025-01-23 | Planned | |
stable2412-2 | ~2025-02-17 | ~2025-02-20 | Planned | |
stable2412-3 | ~2025-03-17 | ~2025-03-20 | Planned | |
(9 more) | ||||
stable2503 | ~2025-02-17 | ~2025-03-31 | ~2026-03-31 | Planned |
stable2503-1 | ~2025-04-28 | ~2025-05-01 | Planned | |
stable2503-2 | ~2025-05-26 | ~2025-05-29 | Planned | |
stable2503-3 | ~2025-06-23 | ~2025-06-26 | Planned | |
(10 more) |
Dates with ~
are estimates.
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:
Apple | |
---|---|
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.
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.
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.
(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
.
Run this command to cut off a release:
python3 scripts/manage.py release cutoff stable2407-2 2024-09-02
With publish
likewise.
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.
- 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