build(cli-test): document the compatible version of slack cli with each release

.changeset/config.json

@@ -7,5 +7,5 @@
   "access": "public",
   "baseBranch": "main",
   "updateInternalDependencies": "patch",
-  "ignore": ["@slack/cli-test"]
+  "ignore": []
 }

.changeset/hungry-friends-tickle.md

@@ -0,0 +1,7 @@
+---
+"@slack/cli-test": patch
+---
+
+build(cli-test): document the compatible version of slack cli with each release
+
+The minimum supported Slack CLI version is now documented in the README instead of being encoded in the package version using build metadata (e.g. `+cli.2.32.2`). Build metadata is stripped by npm during publish, causing version conflicts with previously published versions and breaking the automated release workflow.

.github/maintainers_guide.md

@@ -99,13 +99,15 @@ New official package versions are published when the release PR created from cha
 ### 🚧 Beta Releases
 
 1. Make sure your local `main` branch has the latest changes
+
    - Run `git rebase main` from your feature branch (this will rebase your feature branch from `main`). You can opt for `git merge main` if you are not comfortable with rebasing.
 
    - If you do not have a feature branch, you can also use generic release candidate branch name like `<next-version>rc`, i.e. `2.5.0rc`.
 
 2. For each package to be released, run `npm test --workspace packages/<package-name>` to verify that tests are passing.
 
 3. Bump the version(s) in `package.json`
+
    - The version must be in the format of `Major.Minor.Patch-BetaNamespace.BetaVersion` (ex: `5.10.0-workflowStepsBeta.1`, `2.5.0-rc.1`)
 
    - Make a single commit for the version bump ([Example](https://github.com/slackapi/node-slack-sdk/commit/1503609d79abf035e9e21bad7360e124e4211594))
@@ -115,22 +117,27 @@ New official package versions are published when the release PR created from cha
    - Add appropriate labels, including `release`
 
 4. Once the PR's checks and tests have passed, merge it into the corresponding feature branch on the main repository. If you would like a review on the pull request or feel that the specific release you're doing requires extra attention, you can wait for an approval, but it is optional for this type of PR.
+
    - Update your local main branch: `git pull origin <beta-feature-branch>`
 
    - Add a version tag (ie, `git tag @slack/web-api@5.10.0-workflowStepsBeta.1`)
 
    - Push the new tag up to origin: `git push --tags origin`
 
 5. Publish the release to npm
+
    - Run `npm publish --workspace packages/<package-name> --tag <dist-tag> --otp YOUR_OTP_CODE`
+
      - `<dist-tag>` should be a label representative of the beta release. It could be feature-specific (i.e. `feat-token-rotation`) or it can be a generic release candidate (i.e. `2.5.0rc`). Whatever you decide: it must _not_ be `latest`, as that is reserved for non-beta releases.
 
    - To generate an OTP (One Time Password), use your password generator of choice (Duo, 1Password)
 
 6. Test that the publish was successful
+
    - Run `npm info <PACKAGE_NAME> dist-tags`
 
 7. Create GitHub Release(s) with release notes
+
    - From the repository, navigate to the **Releases** section and draft a new release
 
    - Release notes should mention the beta feature (if applicable), contributors, issues and PRs ([Example](https://github.com/slackapi/node-slack-sdk/releases/tag/%40slack%2Ftypes%401.8.0-workflowStepsBeta.2))
@@ -143,9 +150,7 @@ New official package versions are published when the release PR created from cha
 
 This project is versioned using [Semantic Versioning](http://semver.org/), particularly in the [npm flavor](https://docs.npmjs.com/getting-started/semantic-versioning). Each release is tagged using git. The naming convention for tags is `{package_name}@{version}`. For example, the tag `@slack/web-api@v5.0.0` marks the v5.0.0 release of the `@slack/web-api` package. A single commit will have multiple tags when multiple packages are released simultaneously.
 
-One package that expands upon the standard major.minor.patch version schema typically associated with Semantic Versioning is the `@slack/cli-test` package. This package employs standard major.minor.patch version, in addition to a [build metadata suffix](https://semver.org/#spec-item-10) suffix of the form `+cli.X.Y.Z`, e.g. `0.1.0+cli.2.24.0`. The version after `+cli.` communicates compatibility between the `@slack/cli-test` package and the [Slack CLI](https://docs.slack.dev/tools/slack-cli/) itself.
-
-> The `@slack/cli-test` package must be published manually because our automated release workflow does not support semver build metadata. See [#2483](https://github.com/slackapi/node-slack-sdk/pull/2483) and [#2492](https://github.com/slackapi/node-slack-sdk/pull/2492) for more context.
+The `@slack/cli-test` package documents its minimum supported Slack CLI version in the README.
 
 ### 🪵 Branches
 

packages/cli-test/README.md

@@ -6,7 +6,7 @@ This library is designed to automate the [Slack Platform Command Line Interface]
 
 # Requirements
 
-1. Ensure the [Slack CLI][cli] is installed on your system.
+1. Ensure the [Slack CLI][cli] (version 2.32.2 or higher) is installed on your system.
 2. Export the path to the CLI binary as a `SLACK_CLI_PATH` environment variable.
 
 # Quickstart