Skip to content

Release new version

Kirill Shumilov edited this page Dec 4, 2023 · 8 revisions

Releasing a new version of Smapp

How to

  1. Set the release version to env var to be used later in the process (given the version to release is 0.42.0).

    export SMAPP_NEW_VERSION=0.42.0
    
  2. Create a release branch from develop:

    git checkout develop
    git checkout -b release-${SMAPP_NEW_VERSION:?}
    
  3. Bump Smapp version in package.json

  4. Point on the go-spacemesh version in node/use-version, aka v0.6.1-nightly

    This version should be already released and available on GCS. CI will download the specified version.

  5. Commit and push changes:

    git commit -a -m "Release v${SMAPP_NEW_VERSION:?}"
    git push --set-upstream origin release-${SMAPP_NEW_VERSION:?}
    
  6. Open PR with the title "Release 0.42.0"

    Part of [release process](https://github.com/spacemeshos/smapp/wiki/Release-new-version).
    
  7. When all checks are green and PR builds are ready — check them out and ensure that they work fine.

  8. Push the tag to build the release artifacts

    git tag v${SMAPP_NEW_VERSION:?} && git push origin v${SMAPP_NEW_VERSION:?}
    

    As a consequence CI will build, sign and upload release artifacts to GCS and create a release draft with URLs to the artifacts.

  9. Ensure those release artifacts are downloadable and runnable on each platform.

    If something goes wrong up to this point and you have to make a fix, then delete the tag:

    git tag --delete v${SMAPP_NEW_VERSION:?} &&  git push --delete origin v${SMAPP_NEW_VERSION:?}
    

    In case the fix is related to this particular release (E.G. forgot to bump the Node version), or release processes (something broken in release workflow) you can add commits with fixes in the same branch.

    Otherwise, please do fixes in the separate branches, and merge them into develop. Do not forget to rebase the release branch on top of develop.

    To run building release artifacts next time just repeat the previous step: push the tag.

  10. Prepare release notes (see details below) within the draft created by CI.

    Better to save a draft release. In this case, we have a chance to ensure that we didn't forget anything, run Smapp at least on one platform (to make screenshots), and give a chance for other team members to review this release notes before it will be accessible to the public.

  11. Merge the PR, and publish the release.

  12. Allow users to auto-upgrade for the newer version: update the discovery service.

    Point latestSmappRelease on the new version, aka 0.42.0

Release notes

Here is an example of good release notes: v0.2.2

Keep the contents created by CI and enhance complete it with:

  • Optional: Eye-catching screenshot which illustrates a new feature.

  • "What's Changed" section.

    You can use a built-in auto-generator and tweak it a little bit.

    Each change should be listed here with the reference to PR number and author(s). PR names might be changed to better describe the feature, bug, etc.

    Then all changes should be grouped into categories or their unions:

    • ❗️Breaking changes❗️
    • Features
    • Bug fixes
    • Chore — for some routine like bumping dependencies, fixing ci, etc
    • and others if needed.

    Do not create empty categories and categories with less than 2 PRs.

    In case there were some pre-release builds between releases, then include a list of PRs from pre-release as a separate list.

    At the end of the section place a link to the full changelog from the current version to the previous one (https://github.com/spacemeshos/smapp/compare/v0.41.0...v0.42.0).

  • Contributors

    As it is generated by an auto-generator. Leave here only authors that participated in PRs that are included in the release.

Clone this wiki locally