Skip to content

Latest commit

 

History

History
119 lines (110 loc) · 6.18 KB

RELEASES_CHECKLIST.md

File metadata and controls

119 lines (110 loc) · 6.18 KB

How to release

Generally, we bump and publish the versions of all crates in this mono-repository in lockstep. It does not matter if it's a PATCH, MINOR, MAJOR release.

Reasons for doing it this way:

  • Keeps our RELEASES.md simple and easy to grasp.
    We can still bundle all changes there together and don't have to go to a more fine-grained crate level.
  • Easier to follow reported issues.
    All crates are closely tied together anyway and if someone reports an issue with e.g. 3.1 we know what they mean.
  • Easier to keep the workshop/documentation/playground/user interfaces in sync.
  • Easier for users to follow changes.
    Those will all be listed in one section of the changelog, bundled together, released at the same time.
  • Third party tooling like dependabot can easily extract the changelog.

Examples

Examples (so anything in the integration-tests/ folder) are a bit of a special case in our release pipeline since they are considered as ink! internals and not part of the library per-say.

What this means is that any changes to the examples (breaking or not) should only be considered a PATCH level change. Additionally, they should not be published to crates.io.

Checklist

We'll be using cargo-release to release ink!. There are still a few manual steps though, and we hope to make this more streamlined in the future.

  1. Create a new feature branch off master.
  2. Copy the release notes that appear in the CHANGELOG.md into the PR description.
    • This will cause the individual PRs to be linked to the release in which they are included.
  3. Bump the version in all TOML files to the new version. 
    find . -type f -name *.toml -exec sed -i -e 's/$OLD_VERSION/$NEW_VERSION/g' {} \;
  4. Make sure you've moved the changes in the CHANGELOG.md from [Unreleased] into a new section for the release.
  5. Check that all notable PRs since the last release are now in the new release section, in case the [Unreleased] section was incomplete.
    • Notable changes are changes that affect users in some way. This means that something like a change to our CI pipeline is likely not notable and should not be included.
  6. Make sure you've merged the latest master into your branch.
  7. Open a release PR
    • Wait for approvals from Core team members.
    • Ensure the entire CI pipeline is green.
  8. Before releasing, take note of the release order:
    • ink_e2e is dependent on the cargo-contract crates, which are dependent on the ink "core" crates.
    • Therefore, first release all ink crates except ink_e2e.
    • Release cargo-contract crates.
    • Request update of drink client, which depends on the cargo-contract crates.
    • Release ink_e2e.
  9. The ink_runtime crate depends on a git commit of polkadot-sdk, hence it currently cannot be published to crates.io.
  10. Do a dry run: 
    fd Cargo.toml crates/ | \
grep -v e2e | \
grep -v runtime/ | \
xargs -n1 cargo no-dev-deps publish --allow-dirty --dry-run --manifest-path
    This command ignores the e2e and runtime folders: The e2e crates depend on the cargo-contract/contract-build crate, so if you want to publish those, you need to publish cargo-contract/contract-build first. The runtime is ignored, as it depends on some crates via their git ref. It uses no-dev-deps for publishing, so that the dev-dependencies of ink! are ignored for publishing. They are not needed and due to a cycle it's also not possible to publish with them. Ignoring dev-dependencies is also why --allow-dirty is necessary.
  11. Following a successful dry run, we can now publish to crates.io.
    • This will be done from the release branch itself.
    • This is because it is possible for the dry run to succeed but for the actual publish to fail and require some changes. So before running the next step:
      • Ensure there have been no new commits to master which are not included in this branch.
      • Notify core team members in the Element channel that no PRs should be merged to master during the release.
      • The above is to ensure that the bundled code pushed to crates.io is the same as the tagged release on GitHub.
  12. Publish with 
    fd Cargo.toml crates/ | \
grep e2e | \
xargs -n1 cargo no-dev-deps publish --allow-dirty --manifest-path
  13. Following a successful release from the release PR branch, now the PR can be merged into master
    • Once merged, notify core team members in the Element channel that PRs can be merged again into master
  14. Replace vX.X.X with the new version in the following command and then execute it: 
    git tag -s vX.X.X && git push origin vX.X.X
    • Ensure your tag is signed with an offline GPG key!
    • Alternatively, the Create release GitHub UI below allows creating this tag when creating the release.
  15. Update the ink-examples repository with the content of integration-tests (minus mother, lang-err-integration-tests and mapping-integration-tests). Besides copying those folders over, the only change you need to do manually is to switch the dependencies in the Cargo.toml's to use the published version of your release.
  16. Create a GitHub release for this tag. In the tag overview you'll see your new tag appear. Click the … on the right of the tag and then Create release.
  17. Paste the release notes that appear in the CHANGELOG.md there. The title of the release should be vX.X.X.
  18. Post an announcement to the Telegram channel: https://t.me/inkathon/1
  19. Update the documentation with the new release: