Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update README to include point release instructions #536

Open
wants to merge 6 commits into
base: main
Choose a base branch
from
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
26 changes: 23 additions & 3 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -4,7 +4,7 @@ This repository houses the code required to build the runtimes for Polkadot, Kus

## Structure

Each leaf folder contains one runtime crate:
Runtimes can be found in the `relay` and `system-parachains` top-level folders, each leaf folder of which contains one runtime crate:

<!-- Run "tree -I 'target' -d -L 3" and then delete some folders from Polkadot and Kusama. -->

Expand All @@ -21,8 +21,15 @@ Each leaf folder contains one runtime crate:
│ └── bridge-hub-polkadot
├── collectives
│ └── collectives-polkadot
└── gluttons
└── glutton-kusama
├── coretime
│ ├── coretime-kusama
│ └── coretime-polkadot
├── encointer
├── gluttons
│ └── glutton-kusama
└── people
├── people-kusama
└── people-polkadot
```

## Approval rights
Expand Down Expand Up @@ -61,6 +68,19 @@ The release process is building all runtimes and then puts them into a release i

The format of [`CHANGELOG.md`](CHANGELOG.md) is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/).

### Point releases

In order to release a patch or fix outside the normal release process, some additional steps are needed.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not ultra happy with this process, but until someone has automated it, it is good to have it written down.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ideally there would be a bot command so you could call /cmd point-release or whatever in a comment on a PR made against the x.y.z branch, the bot would create branch x.y.b, rebase the PR to x.y.b then trigger the release process from release-* branch when it sees the usual changelog changes when the branch is merged.

Probably would need to know which release is on chain and only allow +1s to avoid lots of branches being made.


To submit a fix to release `x.y.z` and make a point release:

- Make your changes based on x.y.z
- Create a branch `x.y.b` from the most recent release, where `b = z + 1` (contact a maintainer)
- Make a PR against the branch `x.y.b`
- Trigger the release process manually (contact a maintainer)
- Check for other planned releases which originally targeted the same semver version and post on the issue letting them know that they should bump
- Once the release is out, amend the GitHub release and delete all unchanged runtime blobs. Highlight if this release only affects some runtimes (contact a maintainer)
- Backport your changes to the `CHANGELOG.md` to the main branch
## Release guidelines

Here is an overview of the recommended steps.
Expand Down
Loading