From d60ca962473d1a2e3ce0ac1b4c59db32e5df42ac Mon Sep 17 00:00:00 2001 From: Alissa Renz Date: Thu, 10 Jun 2021 11:38:31 -0700 Subject: [PATCH 1/2] Update Maintainers Guide --- .github/maintainers_guide.md | 233 ++++++++++++++--------------------- 1 file changed, 95 insertions(+), 138 deletions(-) diff --git a/.github/maintainers_guide.md b/.github/maintainers_guide.md index 5d4137871..e139c7543 100644 --- a/.github/maintainers_guide.md +++ b/.github/maintainers_guide.md @@ -1,199 +1,162 @@ -# Maintainers Guide +# Maintainer's Guide -> ⚠️ This maintainers guide is out of date. Progress on updating it is being [tracked](https://github.com/slackapi/node-slack-sdk/issues/748). +This document describes tools, tasks and workflow that one needs to be familiar with in order to effectively maintain this project. If you use this package within your own software but don't plan on modifying it, this guide is **not** for you. Please refer to the [Contributor's Guide](https://github.com/slackapi/node-slack-sdk/blob/main/.github/contributing.md). -This document describes tools, tasks and workflow that one needs to be familiar with in order to effectively maintain -this project. If you use this package within your own software but don't plan on modifying it, this guide is -**not** for you. +## 🛠 Tools +Maintaining this project requires installing [Node.js](https://nodejs.org). All of the remaining tools are downloaded as `devDependencies`, which means you'll have them available once you run `npm install` in a working copy of this repository. -## Tools +## ✅ Tasks -Maintaining this project requires installing [Node.js](https://nodejs.org) in your development environment. All of the -remaining tools are downloaded as `devDependencies`, which means you'll have them available once you run `npm install` -in a working copy of this repository. +### ⚗️ Testing and Linting +To run tests for a given package, navigate to the package directory and run `npm test`. To run linting, run `npm run lint`. -In particular, [`lerna`](https://lerna.js.org/) is a tool you should become familiar with. This project is home to -several packages, and lerna makes it easier to manage operations across the set of packages. The very next thing you -should do is run `npx lerna bootstrap` in the root of this project to install dependencies for each of the packages, -and to allow lerna to link them to each other. +This project has tests for individual packages as `*.spec.js` files and inside of each's respective `test` directory. It also has integration tests in the `integration-tests` directory under the root `support` directory. -## Tasks +Upon opening a PR, tests are executed by GitHub Actions, our continuous integration system. GitHub Actions runs several, more granular builds in order to report on success and failure in a more targeted way. -### Testing - -This project has tests for individual packages as `*.spec.js` files and inside of each's respective `test` directory. It also has -integration tests in the `integration-tests` directory under the root `support` directory. You can run the entire test -suite using the npm script `npm test` at the top level. This script will use Lerna to invoke tests in each package and -the integration tests. - -Tests are executed by GitHub Actions, our continuous integration system, slightly differently. GitHub Actions runs several, more -granular builds in order to report on success and failure in a more useful (targeted) way. There is one build for each -package on each supported version of Node, as well as one for the integration tests on each supported version of Node. -GitHub Actions also runs linting in each package, which is separate from tests so you can run tests locally frequently without -having to block for fixing styling problems. Lastly, GitHub Actions uploads the coverage report for the tests ran within the -build to Codecov, our coverage reporting system. GitHub reports status on each PR. Codecov aggregates all the coverage -reports, and separate reports status on each PR. The configuration is stored in `.github/workflows/ci-build.yml`. + - There is one build for each package on each supported version of Node, as well as one for the integration tests on each supported version of Node. + + - GitHub Actions runs linting in each package, which is separate from tests so you can run tests locally frequently without having to block for fixing styling problems. + + - GitHub Actions uploads the coverage report for the tests ran within the build to Codecov, our coverage reporting system. GitHub reports status on each PR. Codecov aggregates all the coverage reports, and separate reports status on each PR. The configuration is stored in `.github/workflows/ci-build.yml`. -Test code should be written in syntax that runs on the oldest supported Node.js version, without transpiling. This -ensures that backwards compatibility is tested and the APIs look reasonable in versions of Node.js that do not support -the most modern syntax. +Test code should be written in syntax that runs on the oldest supported Node.js version. This ensures that backwards compatibility is tested and the APIs look reasonable in versions of Node.js that do not support the most modern syntax. We have included `launch.json` files that store configuration for `vscode` debugging in each pacakge. This allows you to set breakpoints in test files and interactively debug. Open the project in `vscode` and navigate to the debug screen on the left sidebar. The icon for it looks like a little lock bug with an x inside. At the top in `vscode`, select the configuration to run and press the green play icon to start debugging. Alternatively, on mac, you can press `cmd + shift + d` to get to the debug screen and `F5` to start debugging. If you are using `vscode` debugging, don't forget to lint the source (`npm run lint`) manually. Also, for verifying the behavior with the real Slack server-side and developer experience with installed packages, you can run the tests amd scripts under `prod-server-integration-tests`. Refer to the README file in the directory for details. These tests are supposed to be run in the project maintainers' manual execution. They are not part of CI builds for now. -### Generating Documentation - +### 📄 Generating Documentation The documentation is built using [Jekyll](https://jekyllrb.com/) and hosted with GitHub Pages. The source files are contained in the `docs` directory. Reading the Jekyll configuration in `docs/_config.yml` is helpful to understand how -the documentation is organized and built. To build the docs, you will have to run the command `bundle exec jekyll serve` -in the docs directory. A prerequisite to building the docs locally is to have ruby ~2.5.3 and install the dependencies by running `bundle install`. +the documentation is organized and built. -To build reference documentation, in the root of this repo, run `npm run ref-docs`. This will generate reference docs and put them in the `docs/_reference` directory. -Currently, reference docs need to be built manually running this command and checked into GitHub. +To build the docs locally, navigate to the `docs` directory. First ensure you have Ruby ~2.5.3 and install the dependencies by running `bundle install`. Then, run the command `bundle exec jekyll serve`. You will then be provided with a local URL that you can use to view the build. + +To build reference documentation, in the root of this repo, run `npm run ref-docs`. This will generate reference docs and put them in the `docs/_reference` directory. Currently, reference docs need to be built manually running this command and checked into GitHub. **TODO**: Update this doc once building of reference docs is automated to happen on each commit to the repo Reference docs are built by using various open source tools and formats. This includes [API-Extractor](https://api-extractor.com/), [mdast](https://github.com/syntax-tree/mdast), and [Remark](https://github.com/remarkjs/remark). [Read more about the reference docs pipeline](https://github.com/slackapi/node-slack-sdk/pull/831#issue-299509206). -### Releasing +### 🚀 Releases +_For beta releases, see [**Beta Releases**](https://github.com/slackapi/node-slack-sdk/blob/main/.github/maintainers_guide.md#beta-releases) section below_ -Before releasing, it's important to understand that you may release several packages simultaneously. While `lerna` can -offer its view on which packages have changed since the last release, you should **verify version changes yourself** -before continuing with the release. If you find a file or set of files that should be allowed to change without -publishing a package, it might be a good idea to add it to the `ignoreChanges` setting in `lerna.json`. +Releasing can feel intimidaitng at first, but rest assured: if you make a mistake, don't fret! npm allows you to unpublish a release within the first 72 hours of publishing (you just won’t be able to use the same version number again). Venture on! -If you make a mistake, don't fret. NPM allows you to unpublish a release within the first 72 hours of publishing, but you won’t be able to use the same version number again. Venture on! +1. Navigate to the specific package you're releasing in the `packages/` directory. -> If you have any doubt whether your working copy is in good shape to do a release, here is a succinct way to get a -> fresh start: `npx lerna clean && npx lerna bootstrap`. +2. Run `npm run test && npm run lint` to verify that everything is working and free of linting errors. -0. Verify that everything is in order by testing and linting locally before proceeding: `npm run test && npm run lint`. +3. Bump the version in `package.json`. -1. First, lets confirm lerna wants to release the correct packages. Run `npx lerna changed` to see which packages lerna thinks are ready for release. If that looks good, follow through with the command to create a tagged commit `npx learna version`. - * Lerna will ask you to make selections for the version increment on each package it plans to tag for release. You - should already have an idea of what the appropriate semver increment (patch, minor, or major) you intend to create. - If Lerna asks about a package you didn't intend to release, it's best to bail at this point - (CTRL+C). - * If lerna wants to release more packages than you want to, it's best to run the commands individually. This includes the following: - - bump the version in `package.json` for all packages you are releasing - - Make a single commit for the version bump. The commit message should be similar to a [previous one](https://github.com/slackapi/node-slack-sdk/commit/1503609d79abf035e9e21bad7360e124e4211594). - - Add version tags for each package you are about to release. Ex `git tag @slack/web-api@5.6.0` - - Push commit and tags up to your fork: `git push username main --tags`. - - Create pull request for review. It should be similar to a [previous one](https://github.com/slackapi/node-slack-sdk/pull/1059) + - Make a single commit for the version bump [(Example)](https://github.com/slackapi/node-slack-sdk/commit/1503609d79abf035e9e21bad7360e124e4211594) -2. Merge into main repository - * Once tests pass and a reviewer has approved, merge the pull request. - * Update your local main branch `git rebase origin main` (or `git pull origin main`) - * Push the new tag up to origin `git push --tags origin`. + - Create a pull request for the version change [(Example)](https://github.com/slackapi/node-slack-sdk/pull/1059) -3. Publish the release(s) to npm - * If you are using learna, use `NPM_CONFIG_OTP=xxxxxx npx lerna publish from-package` You should have [2FA set up with NPM](https://docs.npmjs.com/about-two-factor-authentication), and the - `NPM_CONFIG_OTP` value should be set to the one time password from your configured second factor device. If the - publishing process takes longer than the expiration time of the value (30 seconds), then you may see a publish - failure. You can try again as soon as the value changes if you think you can beat the timeout, or you can run - `npm publish . --otp YOUR_OTP_CODE` in each of the package directories. - * If you are releasing without learna, change into the package directory and run `npm publish . --otp YOUR_OTP_CODE`. + - Add appropriate labels, including `release` -4. Close GitHub Milestone(s), create GitHub Release(s), and add release notes. - * Move any unfinished, open issues to the next GitHub Milestone - * Close the relevant GitHub Milestone(s) for the release(s) - * Release notes should mention contributors (@-mentions) and issues/PRs (#-mentions). - * Example release: https://github.com/slackapi/node-slack-sdk/releases/tag/%40slack%2Fweb-api%406.2.0 +4. Once the PR has been approved and tests have passed, merge it into the main repository. -5. (Slack Internal) Communicate the release internally. Include a link to the GitHub Release(s). + - Update your local main branch: `git pull origin main` -6. Announce on Bot Developer Hangout (`dev4slack.slack.com`) in **#slack-api**. + - Add a version tag (ie, `git tag @slack/web-api@5.6.0`) -7. (Slack Internal) Tweet? Not necessary for patch updates, might be needed for minor updates, definitely needed for - major updates. Include a link to the GitHub Release(s). + - Push the new tag up to origin: `git push --tags origin` -### Beta Releases +5. Publish the release to npm -#### **Get Feature Branch Ready** + - Run `npm publish . --otp YOUR_OTP_CODE` -1. Make sure your local `main` branch has the latest changes from GitHub + - To generate an OTP (One Time Password), use your password generator of choice (Duo, 1Password) -2. Run `git rebase main` from your feature branch. This command will rebase your feature branch from `main`. You can opt for `git merge main` if you are not comfortable with rebasing. +6. Close GitHub Milestone(s) -3. Make sure all tests and linting pass by running `npm run test && npm run lint` + - Close the relevant GitHub Milestone(s) for the release(s) + + - Move any unfinished, open issues to the next GitHub Milestone -#### **Update the Package Version** +7. Create GitHub Release(s) with release notes -1. Update the release version in `package.json` - - Use the existing version and add a hyphen to name the beta release (ex: `5.10.0-workflowStepsBeta.1`) - - Note: the beta version must be in the format of `Major.Minor.Patch-BetaNamespace.BetaVersion` + - From the repository, navigate to the **Releases** section and draft a new release -2. Make a single commit for this version bump. The commit message should be in the following format: + - Release notes should mention contributors, issues and PRs [(Example)](https://github.com/slackapi/node-slack-sdk/releases/tag/%40slack%2Fweb-api%406.2.0) -``` -Publish +8. Communicate the release (as appropriate) -- @slack/web-api@5.11.0-workflowStepsBeta.1 -- @slack/types@1.8.0-workflowStepsBeta.1 -``` + - **Internal** + + - Include a brief description and link to the GitHub release -#### **Add Git Tags** + - **External** -1. Add a git tag for every package you are releasing + - **Bot Developer Hangout** (`dev4slack.slack.com`) in **#slack-api** + + - **Twitter**: Primarily for major updates. Coordinate with Developer Marketing. - - Example: `git tag @slack/web-api@5.10.0-workflowStepsBeta.1` +### 🚧 Beta Releases +1. Navigate to the specific package you're releasing in the `packages/` directory. -2. Push all tags and commits up to the feature branch on `origin` via `git push origin feature-branch --tags` +2. Make sure your local `main` branch has the latest changes -#### **Publish to npm** + - 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. -1. Navigate to the specific package you wish to publish +3. Run `npm run test && npm run lint` to verify that everything is working and free of linting errors. -2. Publish to npm via `npm publish . --otp YOUR_OTP_CODE` +4. Bump the version in `package.json` - - To obtain an OTP (One Time Password) code, use a utility like Duo or 1Password + - The version must be in the format of `Major.Minor.Patch-BetaNamespace.BetaVersion` (ex: `5.10.0-workflowStepsBeta.1`) -3. Immediately after publishing to npm, update the `dist-tags`: + - Make a single commit for the version bump [(Example)](https://github.com/slackapi/node-slack-sdk/commit/1503609d79abf035e9e21bad7360e124e4211594) - - First update the `latest` `dist-tag` to the previous non-beta release: `npm dist-tag add @slack/web-api@5.10.0 latest --otp YOUR_OTP_CODE`. + - Create a pull request for the version change against the corresponding feature branch in the main repository [(Example)](https://github.com/slackapi/node-slack-sdk/pull/1244) - - If you are adding or updating a specific feature/beta `dist-tag`, run: `npm dist-tag add @slack/web-api@5.10.0-workflow-steps-beta.1 feat-workflow-steps --otp YOUR_OTP_CODE` + - Add appropriate labels, including `release` -4. In order to test that the publish was successful, install the package from npm into a test project via `npm install @slack/web-api@feat-workflow-steps`. Verify that the `package.json` looks as you'd expect. +5. Once the PR has been approved and tests have passed, merge it into the corresponding feature branch on the main repository. -#### **Create Release and Publish Release Notes** + - Update your local main branch: `git pull origin ` -1. From the repository's Github, navigate to the **Releases** section and draft a new release - -2. Summarize the release + - Add a version tag (ie, `git tag @slack/web-api@5.10.0-workflowStepsBeta.1`) - - Release notes should mention what changes are present, including contributors (@mentions) and associated issues/PRs (#mentions) for each. - - - Use the following as a template, viewable [here](https://github.com/slackapi/node-slack-sdk/releases/tag/%40slack%2Fweb-api%405.11.0). + - Push the new tag up to origin: `git push --tags origin` + +5. Publish the release to npm -3. Check the **This is a pre-release** checkbox + - Run `npm publish . --otp YOUR_OTP_CODE` -4. And finally, go ahead and click **Update release** and celebrate! 🎉 + - To generate an OTP (One Time Password), use your password generator of choice (Duo, 1Password) -## Workflow +6. Immediately after publishing, update the `dist-tags` -### Versioning and Tags + - Update the `latest` `dist-tag` to the **previous non-beta release**: `npm dist-tag add @slack/web-api@5.10.0 latest --otp YOUR_OTP_CODE`. -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. + - Add a `dist-tag` name for the beta feature: `npm dist-tag add @slack/web-api@5.10.0-workflow-steps-beta.1 feat-workflow-steps --otp YOUR_OTP_CODE` -While `lerna` is used for management of this repository, it is configured for **independent** versioning. This allows -each package to evolve in a less tightly-coupled manner. Specifically, if one package were to require a major version -increment, it could do so without unnecessarily affecting all the other packages. +7. Test that the publish was successful -### Branches + - Run `npm info dist-tags` -`main` is where active development occurs. Long running named feature branches are occasionally created for -collaboration on a feature that has a large scope (because everyone cannot push commits to another person's open Pull -Request). After a major version increment, a maintenance branch for the older major version is left open (e.g. `v3`, -`v4`, etc) +8. Create GitHub Release(s) with release notes -### Issue Management + - 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) + + - Select the **This is a pre-release** checkbox + +## 📥 Workflow + +### 🔖 Versioning and Tags +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. + +### 🪵 Branches +`main` is where active development occurs. Long running named feature branches are occasionally created for collaboration on a feature that has a large scope (because everyone cannot push commits to another person's open Pull Request). After a major version increment, a maintenance branch for the older major version is left open (e.g. `v3`, `v4`, etc). + +When resolving issues or implementing features into the repository, you will almost always work off of a dedicated branch that lives on your forked copy of the repository. + +## 👩🏻‍🔧 Issue Management +### 🏷 Labels Labels are used to run issues through an organized workflow. Here are the basic definitions: * `bug`: A confirmed bug report. A bug is considered confirmed when reproduction steps have been documented and the @@ -215,13 +178,7 @@ Labels are used to run issues through an organized workflow. Here are the basic * `semver:major|minor|patch`: Metadata about how resolving this issue would affect the version number. * `pkg:*`: Metadata about which package(s) this issue affects. -**Triage** is the process of taking new issues that aren't yet "seen" and marking them with a basic level of information -with labels. An issue should have **one** of the following labels applied: `bug`, `enhancement`, `question`, -`needs feedback`, `docs`, `tests`, or `discussion`. - -Issues are closed when a resolution has been reached. If for any reason a closed issue seems relevant once again, -reopening is great and better than creating a duplicate issue. - -## Everything else +### 📬 Triage +Triaging is the process of investigating new issues, assigning them an appropriate label, and responding to the submitting developer. An issue should have **one** of the following labels applied: `bug`, `enhancement`, `question`, `needs feedback`, `docs`, `tests`, or `discussion`. -When in doubt, find the other maintainers and ask. +Issues are closed when a resolution has been reached. If for any reason a closed issue seems relevant once again, reopening the issue is preferable over creating a duplicate issue. \ No newline at end of file From da31556d2d0a16ae92d23b5df1663c991a37cd1f Mon Sep 17 00:00:00 2001 From: Alissa Renz Date: Thu, 10 Jun 2021 17:35:09 -0700 Subject: [PATCH 2/2] Incorporate PR feedback --- .github/maintainers_guide.md | 40 ++++++++++++++++++++---------------- 1 file changed, 22 insertions(+), 18 deletions(-) diff --git a/.github/maintainers_guide.md b/.github/maintainers_guide.md index e139c7543..18ec68275 100644 --- a/.github/maintainers_guide.md +++ b/.github/maintainers_guide.md @@ -8,7 +8,7 @@ Maintaining this project requires installing [Node.js](https://nodejs.org). All ## ✅ Tasks ### ⚗️ Testing and Linting -To run tests for a given package, navigate to the package directory and run `npm test`. To run linting, run `npm run lint`. +The Node SDK is made up of multiple, individual packages, each with their own tests. As such, tests are run on a per-package basis. To run tests for a given package, navigate to the package's directory (ie, `packages/web-api`) and run `npm test`. To run linting, run `npm run lint`. This project has tests for individual packages as `*.spec.js` files and inside of each's respective `test` directory. It also has integration tests in the `integration-tests` directory under the root `support` directory. @@ -27,9 +27,7 @@ We have included `launch.json` files that store configuration for `vscode` debug Also, for verifying the behavior with the real Slack server-side and developer experience with installed packages, you can run the tests amd scripts under `prod-server-integration-tests`. Refer to the README file in the directory for details. These tests are supposed to be run in the project maintainers' manual execution. They are not part of CI builds for now. ### 📄 Generating Documentation -The documentation is built using [Jekyll](https://jekyllrb.com/) and hosted with GitHub Pages. The source files are -contained in the `docs` directory. Reading the Jekyll configuration in `docs/_config.yml` is helpful to understand how -the documentation is organized and built. +The documentation is built using [Jekyll](https://jekyllrb.com/) and hosted with GitHub Pages. The source files are contained in the `docs` directory. Reading the Jekyll configuration in `docs/_config.yml` is helpful to understand how the documentation is organized and built. To build the docs locally, navigate to the `docs` directory. First ensure you have Ruby ~2.5.3 and install the dependencies by running `bundle install`. Then, run the command `bundle exec jekyll serve`. You will then be provided with a local URL that you can use to view the build. @@ -44,19 +42,25 @@ _For beta releases, see [**Beta Releases**](https://github.com/slackapi/node-sla Releasing can feel intimidaitng at first, but rest assured: if you make a mistake, don't fret! npm allows you to unpublish a release within the first 72 hours of publishing (you just won’t be able to use the same version number again). Venture on! -1. Navigate to the specific package you're releasing in the `packages/` directory. +1. Check the status of the package's GitHub Milestone for issues that should be shipped with the release. + + - If all issues have been closed, continue with the release. + + - If issues are still open, discuss with the team about whether the open issues should be moved to a future release or if the release should be held off until the issues are resolved. -2. Run `npm run test && npm run lint` to verify that everything is working and free of linting errors. +2. Navigate to the specific package you're releasing in the `packages/` directory. -3. Bump the version in `package.json`. +3. Run `npm run test && npm run lint` to verify that everything is working and free of linting errors. - - Make a single commit for the version bump [(Example)](https://github.com/slackapi/node-slack-sdk/commit/1503609d79abf035e9e21bad7360e124e4211594) +4. Bump the version in `package.json` (see [Versioning and Tags](https://github.com/slackapi/node-slack-sdk/blob/main/.github/maintainers_guide.md#versioning-and-tags)) - - Create a pull request for the version change [(Example)](https://github.com/slackapi/node-slack-sdk/pull/1059) + - Make a single commit for the version bump ([Example](https://github.com/slackapi/node-slack-sdk/commit/1503609d79abf035e9e21bad7360e124e4211594)) + + - Create a pull request for the version change ([Example](https://github.com/slackapi/node-slack-sdk/pull/1059)) - Add appropriate labels, including `release` -4. Once the PR has been approved and tests have passed, merge it into the main repository. +5. Once the PR has been approved and tests have passed, merge it into the main repository. - Update your local main branch: `git pull origin main` @@ -64,25 +68,25 @@ Releasing can feel intimidaitng at first, but rest assured: if you make a mistak - Push the new tag up to origin: `git push --tags origin` -5. Publish the release to npm +6. Publish the release to npm - Run `npm publish . --otp YOUR_OTP_CODE` - To generate an OTP (One Time Password), use your password generator of choice (Duo, 1Password) -6. Close GitHub Milestone(s) +7. Close GitHub Milestone(s) - Close the relevant GitHub Milestone(s) for the release(s) - Move any unfinished, open issues to the next GitHub Milestone -7. Create GitHub Release(s) with release notes +8. Create GitHub Release(s) with release notes - From the repository, navigate to the **Releases** section and draft a new release - - Release notes should mention contributors, issues and PRs [(Example)](https://github.com/slackapi/node-slack-sdk/releases/tag/%40slack%2Fweb-api%406.2.0) + - Release notes should mention contributors, issues and PRs ([Example](https://github.com/slackapi/node-slack-sdk/releases/tag/%40slack%2Fweb-api%406.2.0)) -8. Communicate the release (as appropriate) +9. Communicate the release (as appropriate) - **Internal** @@ -107,9 +111,9 @@ Releasing can feel intimidaitng at first, but rest assured: if you make a mistak - The version must be in the format of `Major.Minor.Patch-BetaNamespace.BetaVersion` (ex: `5.10.0-workflowStepsBeta.1`) - - Make a single commit for the version bump [(Example)](https://github.com/slackapi/node-slack-sdk/commit/1503609d79abf035e9e21bad7360e124e4211594) + - Make a single commit for the version bump ([Example](https://github.com/slackapi/node-slack-sdk/commit/1503609d79abf035e9e21bad7360e124e4211594)) - - Create a pull request for the version change against the corresponding feature branch in the main repository [(Example)](https://github.com/slackapi/node-slack-sdk/pull/1244) + - Create a pull request for the version change against the corresponding feature branch in the main repository ([Example](https://github.com/slackapi/node-slack-sdk/pull/1244)) - Add appropriate labels, including `release` @@ -141,7 +145,7 @@ Releasing can feel intimidaitng at first, but rest assured: if you make a mistak - 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) + - 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)) - Select the **This is a pre-release** checkbox