Skip to content

Latest commit

 

History

History
63 lines (40 loc) · 3.71 KB

RELEASING.md

File metadata and controls

63 lines (40 loc) · 3.71 KB

Release Instructions

QA

Before any major or minor release, we will run through our QA plan.

Process

We use changesets to manage changelogs and releases.

When creating a PR that should trigger a release you should include a changeset within your PR.

To include a changeset follow these steps:

  1. Run npx changeset add
  2. Follow the prompts, the CLI will ask you to select which packages should have a major, minor and patch bump. Use space to select the packages and hit enter to go to the next step. To skip a prompt (e.g if you changes do not require a major bump) just hit enter without selecting a package.
  3. Enter a short message describing the changes. You can always change the changelog entry by editing the newly created file in .changesets/[name].md
  4. Add the changesets to your PR (git add), commit and push.

A GitHub bot will check if you PR include a changeset file. If it doesn't you will be warned in the PR.

NOTE: You should also do this for the WordPress plugin.

@next releases

Whenever a PR is merged to the develop branch, if it contains a changeset a new PR will be opened automatically against develop to bump versions and push to npm under the next tag. Merging this PR opened by changeset will trigger the release flow.

You do not need to release a new version to NPM on every PR that is merged, you can batch as many PRs as you want. For stable releases though, typically we'd only merge develop into trunk once we're ready for a new stable release.

Here's a summary of the process:

  1. Merge a PR with changesets files into develop
  2. Wait for changeset to open a new PR called Release (next).
  3. Optionally merge more PRs into develop if you want to include other changes in the same release. Doing so will update the Release (next) PR automatically.
  4. Merge the PR opened by changeset into develop.
  5. A new release under the next tag will be pushed to npm.
  6. A new Github Release with the changelog will be created automatically.

Stable releases

Whenever a PR is merged to the trunk branch, if it contains a changeset a new PR will be opened automatically against trunk to bump versions and push to npm under the latest tag. Merging this PR opened by changeset will trigger the release flow.

To promote a next release to a stable release, first make sure to release the @next version by merging the Release (@next) PR opened by changeset. Then open a PR from develop against trunk and merge the Release PR into trunk.

After a new stable version has been released, merge trunk back into develop.

Here's a summary of the process

  1. Follow the process to create a next release and test that the release is good to go.
  2. Merge develop into trunk.
  3. Wait for changeset to open a new PR called Release.
  4. Merge the PR opened by changeset into trunk.
  5. A new release under the latest tag will be pushed to npm.
  6. Merge trunk back into develop.
  7. A new Github Release with the changelog will be created automatically.

Plugin Releases

Before merging any release PR to trunk make sure to manually update the wp/headless-wp/plugin.php file. You can commit the changes to the PR generated by changeset or by pushing to develop directly. Update the following things:

  1. The Version: x.x.x phpdoc line.
  2. The HEADLESS_WP_PLUGIN_VERSION constant.

to the version of the plugin being released. This should match the version changeset is showing in the release PR. If changeset is not picking up the plugin then there's nothing to release to the plugin and you don't need to update the version.