pezkuwichain/pezkuwi-subxt
1
0
Fork 0
mirror of https://github.com/pezkuwichain/pezkuwi-subxt.git synced 2026-06-19 15:51:04 +00:00
Code Issues Packages Projects Releases Wiki Activity

Markdown linter (#1309)

Browse Source 
* Add markdown linting

- add linter default rules
- adapt rules to current code
- fix the code for linting to pass
- add CI check

fix #1243

* Fix markdown for Substrate
* Fix tooling install
* Fix workflow
* Add documentation
* Remove trailing spaces
* Update .github/.markdownlint.yaml

Co-authored-by: Oliver Tale-Yazdi <oliver.tale-yazdi@parity.io>
* Fix mangled markdown/lists
* Fix captalization issues on known words
This commit is contained in:
Chevdor
2023-09-04 11:02:32 +02:00
committed by GitHub
parent 830fde2a60
commit a30092ab42
271 changed files with 6289 additions and 4450 deletions
Download Patch File Download Diff File Expand all files Collapse all files
polkadot/RELEASE.md
+44 -49
View File
@@ -1,57 +1,52 @@
Polkadot Release Process
------------------------
# Polkadot Release Process
### Branches
* release-candidate branch: The branch used for staging of the next release.
Named like `release-v0.8.26`
### Notes
* The release-candidate branch *must* be made in the paritytech/polkadot repo in
order for release automation to work correctly
* Any new pushes/merges to the release-candidate branch (for example,
refs/heads/release-v0.8.26) will result in the rc index being bumped (e.g., v0.8.26-rc1
to v0.8.26-rc2) and new wasms built.
## Branches
* release-candidate branch: The branch used for staging of the next release. Named like `release-v0.8.26`
### Release workflow
## Notes
* The release-candidate branch *must* be made in the `paritytech/polkadot` repo in order for release automation to work
correctly
* Any new pushes/merges to the release-candidate branch (for example, refs/heads/release-v0.8.26) will result in the rc
index being bumped (e.g., v0.8.26-rc1 to v0.8.26-rc2) and new wasm built.
Below are the steps of the release workflow. Steps prefixed with NOACTION are
automated and require no human action.
## Release workflow
Below are the steps of the release workflow. Steps prefixed with NOACTION are automated and require no human action.
1. To initiate the release process:
1. branch master off to a release candidate branch:
- `git checkout master; git pull; git checkout -b release-v0.8.26`
2. In the [substrate](https://github.com/paritytech/substrate) repo, check out the commit used by polkadot (this can be found using the following command in the *polkadot* repo: `grep 'paritytech/substrate' Cargo.lock | grep -E '[0-9a-f]{40}' | sort | uniq `
3. Branch off this **substrate** commit into its own branch: `git branch -b polkadot-v0.8.26; git push origin refs/heads/polkadot-v0.8.26`
4. In the **polkadot** repository, use [diener](https://github.com/bkchr/diener/) to switch to this branch: `diener update --branch "polkadot-v0.8.26" --substrate`. Update Cargo.lock (to do this, you can run `cargo build` and then ctrl+c once it finishes fetching and begins compiling)
5. Push the **polkadot** `release-v0.8.26` branch to Github: `git push origin refs/heads/release-v0.8.26`
2. NOACTION: The current HEAD of the release-candidate branch is tagged `v0.8.26-rc1`
3. NOACTION: A draft release and runtime WASMs are created for this
release-candidate automatically. A link to the draft release will be linked in
the internal polkadot matrix channel.
4. NOACTION: A new Github issue is created containing a checklist of manual
steps to be completed before we are confident with the release. This will be
linked in Matrix.
5. Complete the steps in the issue created in step 4, signing them off as
completed
6. (optional) If a fix is required to the release-candidate:
1. branch master off to a release candidate branch: - `git checkout master; git pull; git checkout -b release-v0.8.26`
1. In the [Substrate](https://github.com/paritytech/substrate) repo, check out the commit used by Polkadot (this can
be found using the following command in the *Polkadot* repo: `grep 'paritytech/substrate' Cargo.lock | grep -E
'[0-9a-f]{40}' | sort | uniq`
1. Branch off this **Substrate** commit into its own branch: `git branch -b polkadot-v0.8.26; git push origin
refs/heads/polkadot-v0.8.26`
1. In the **Polkadot** repository, use [diener](https://github.com/bkchr/diener/) to switch to this branch: `diener
update --branch "polkadot-v0.8.26" --substrate`. Update Cargo.lock (to do this, you can run `cargo build` and then
ctrl+c once it finishes fetching and begins compiling)
1. Push the **Polkadot** `release-v0.8.26` branch to Github: `git push origin refs/heads/release-v0.8.26`
1. NOACTION: The current HEAD of the release-candidate branch is tagged `v0.8.26-rc1`
1. NOACTION: A draft release and runtime WASMs are created for this release-candidate automatically. A link to the draft
release will be linked in the internal Polkadot matrix channel.
1. NOACTION: A new Github issue is created containing a checklist of manual steps to be completed before we are
confident with the release. This will be linked in Matrix.
1. Complete the steps in the issue created in step 4, signing them off as completed
1. (optional) If a fix is required to the release-candidate:
1. Merge the fix with `master` first
2. Cherry-pick the commit from `master` to `release-v0.8.26`, fixing any
merge conflicts. Try to avoid unnecessarily bumping crates.
3. Push the release-candidate branch to Github - this is now the new release-
candidate
4. Depending on the cherry-picked changes, it may be necessary to perform some
or all of the manual tests again.
5. If there are **substrate** changes required, these should be cherry-picked to the substrate `polkadot-v0.8.26` branch and pushed, and the version of substrate used in **polkadot** updated using `cargo update -p sp-io`
7. Once happy with the release-candidate, tag the current top commit in the release candidate branch and push to Github: `git tag -s -m 'v0.8.26' v0.8.26; git push --tags`
9. NOACTION: The HEAD of the `release` branch will be tagged with `v0.8.26`,
and a final draft release will be created on Github.
1. Cherry-pick the commit from `master` to `release-v0.8.26`, fixing any merge conflicts. Try to avoid unnecessarily
bumping crates.
1. Push the release-candidate branch to Github - this is now the new release- candidate
1. Depending on the cherry-picked changes, it may be necessary to perform some or all of the manual tests again.
1. If there are **Substrate** changes required, these should be cherry-picked to the Substrate `polkadot-v0.8.26`
branch and pushed, and the version of Substrate used in **Polkadot** updated using `cargo update -p sp-io`
1. Once happy with the release-candidate, tag the current top commit in the release candidate branch and push to Github:
`git tag -s -m 'v0.8.26' v0.8.26; git push --tags`
1. NOACTION: The HEAD of the `release` branch will be tagged with `v0.8.26`, and a final draft release will be created
on Github.
### Security releases
## Security releases
Occasionally there may be changes that need to be made to the most recently
released version of Polkadot, without taking *every* change to `master` since
the last release. For example, in the event of a security vulnerability being
found, where releasing a fixed version is a matter of some expediency. In cases
like this, the fix should first be merged with master, cherry-picked to a branch
forked from `release`, tested, and then finally merged with `release`. A
sensible versioning scheme for changes like this is `vX.Y.Z-1`.
Occasionally there may be changes that need to be made to the most recently released version of Polkadot, without taking
*every* change to `master` since the last release. For example, in the event of a security vulnerability being found,
where releasing a fixed version is a matter of some expediency. In cases like this, the fix should first be merged with
master, cherry-picked to a branch forked from `release`, tested, and then finally merged with `release`. A sensible
versioning scheme for changes like this is `vX.Y.Z-1`.