Skip to content

RELEASE.md

Latest commit

 

History

History
100 lines (84 loc) · 6.02 KB

RELEASE.md

File metadata and controls

100 lines (84 loc) · 6.02 KB
Raw

Releasing Rindo

Rindo can either be released by CI/CD (via GitHub Actions), or manually. An automated release is the preferred way of creating a new release of the project. Manual releases should only be performed when there are extenuating circumstances preventing an automated release.

Automated Releases

  1. Call a code-freeze in the Rindo team channel
  2. Check that Rindo's Merge Queue is empty (nothing is queued for merge).
  3. Run the Rindo Production Release PR Creation Workflow in GitHub
    1. Run the workflow from the main branch, unless the release is for a previous major version of Rindo. In that scenario, select the v#-maintenance branch corresponding to the version of Rindo being released. For example, v3-maintenance to release a new version of Rindo v3.
    2. Rindo follows semantic versioning. Select the appropriate version from the dropdown for this release.
    3. Hit "Run Workflow" and wait for a new pull request to be created.
  4. Navigate to the pull request that was opened as a result of running the Rindo Production Release PR Creation Workflow.
  5. Complete the following (temporary) steps:
    1. Close the pull request and reopen it. This allows actions that the team gates pull requests on to run.
    2. Mark the pull request as ready for review.
  6. Ask the Rindo team for an approval on the PR. Only one approval is required for pull requests that only include the version bump/prerelease commit.
  7. Once approved, add it to the merge queue.
  8. ⚠️ Wait for the pull request to land before continuing to the next step. ⚠️
  9. Run the Rindo Production Release Workflow
    1. Rindo should be published under the latest tag, unless the release is for a previous major version of Rindo.
    2. The base branch should be set to main, unless the release is for a previous major version of Rindo.
    3. Tail the logs to verify everything runs successfully.
  10. Proceed to the Follow-Up section of this document to run manual follow-up tasks.

Manual Releases

⚠️ Manual releases should only be performed when there are extenuating circumstances that prevent an automated one from occurring ⚠️

✍️ Authoring permissions are needed for an individual to perform a manual release. If needed, please ping FamilyJS leadership. ✍️

  1. Call a code-freeze in the Rindo team channel
  2. Run npm run clean locally to clear out any cached build artifacts.
  3. Run npm run release.prepare. This will install dependencies, bundle Rindo, run tests, etc.
  4. Check the CHANGELOG.md and make sure it includes all the changes that have landed since the last release.
  5. Commit the changes - use the commit message ' v'. e.g. git commit -m '🤦‍ v2.7.0' (note the emoji is used literally, as opposed to ':facepalm:').
  6. Run npm run release, which will push the commit/tag to GitHub and publish to NPM.
  7. Proceed to the Follow-Up section of this document to run manual follow-up tasks.

Follow-Up Steps

The following steps should be always run, regardless of whether an automated or manual release was performed.

  1. Publish the release notes in GitHub using GitHub's release notes form.

    1. Set the tag dropdown to the newly-released version's git tag

    2. Set the version title to [VERMOJI] v[VERSION] ([yyyy.mm.dd]). For example, v4.2.0 has a vermoji of 🏕, and was released on 2024.02.18. As a result, it was released with the title of 🏕 4.2.0 (2024-02-18).

    3. Copy the raw contents of CHANGELOG.md into the body

    4. Ensure that the release is set as the latest (so long as we're not published a pre-release)

    5. If anyone from the community contributed commit(s) to this release, append the following to the end of the GitHub release notes:

      ## Thanks

🎉 Thanks <GitHub_Usernames> for their contributions! 🎉

    6. Hit "Publish Release"

  2. Navigate to the Rindo Site repository and:

    1. Merge any open PRs containing documentation that has been approved, but not merged that is related to the release. Such PRs should be labelled as do not merge: waiting for next rindo release. It's a good idea to review all PRs though, just in case.
    2. If the current release is a major or minor version, open a pull request creating a new version of the docs by following the guide in the rindo-site repo.

  3. If there are any 'next' branches in GitHub, say for a future major version of Rindo (e.g. v5.0.0-dev), now is a good time to rebase them against the main branch.

  4. End the code freeze in the Rindo team Slack channel.

  5. Perform the following tasks in JIRA:

    1. Ask someone with appropriate permissions to mark this version of Rindo as 'released' in JIRA on the 'Releases' page.
    2. Ask someone with appropriate permissions to stub out the next release and task for the release in JIRA.

  6. Ensure all GitHub Issues associated with stories/tasks that shipped in this version of Rindo are closed.

    1. For each issue, add a comment stating the version of Rindo that included the fix/feature (be sure to update the version number and tag):

      The fix for this issue has been released as a part of today's [Rindo
vNUMBER release](https://github.com/rindojs/rindo/releases/tag/TAG).

  7. If there's a blog post to go out (either today or this week), let the folks in the #ask-family-devrel channel know about the release and that the blog can go out. When the blog goes out, put an announcement in the #announcements channel in Discord.