From 39fc4e0a5ae1cf30594f13a310eb39313d17e0cf Mon Sep 17 00:00:00 2001 From: Andrew Duthie Date: Thu, 25 Feb 2021 08:27:18 -0500 Subject: [PATCH] Add prerequisites text describing permissions process --- README.md | 21 +++++++++++---------- 1 file changed, 11 insertions(+), 10 deletions(-) diff --git a/README.md b/README.md index ecd6fce6..3bf1686e 100644 --- a/README.md +++ b/README.md @@ -58,23 +58,24 @@ More information can be found in Federalist’s [How Builds Work](https://federa When you're ready to release a new version of the `identity-style-guide` package there are just a few steps to take. -1. Make sure all the changes intended for release are merged into the `main` branch. -2. Check out the main branch on your local machine by running `git checkout main`. -3. Decide the version number for the new release. +Before starting, make sure that all changes intended for release should be merged into the `main` branch. You will need permissions to publish the package to npm. Check current package owners by running `npm owner ls` or by consulting the list of admins through the [Services and Accounts handbook page](https://handbook.login.gov/articles/accounts.html). If you do not have access, contact an owner to have access granted or to publish on your behalf. + +1. Check out the main branch on your local machine by running `git checkout main`. +2. Decide the version number for the new release. - The `CHANGELOG.md` should ideally include all pending changes under an "Unreleased" heading. - This project uses [semantic versioning](https://semver.org/): breaking changes should bump the major version, backwards-compatible changes should bump the minor version, and bug fixes should bump the patch version. -4. Since the main branch is protected, you will need to bump the version in a new branch and open a pull request. Start by creating a new branch. +3. Since the main branch is protected, you will need to bump the version in a new branch and open a pull request. Start by creating a new branch. - Example: `git checkout -b release-4-3-1` -5. Change the "Unreleased" heading in `CHANGELOG.md` to the version you decided in Step 3. Commit this change to your new branch. -6. Run `npm version` to bump the package version, passing one of `patch`, `minor`, or `major` depending on what you had decided in Step 3 for the next version. +4. Change the "Unreleased" heading in `CHANGELOG.md` to the version you decided in Step 3. Commit this change to your new branch. +5. Run `npm version` to bump the package version, passing one of `patch`, `minor`, or `major` depending on what you had decided in Step 3 for the next version. - Example: `npm version patch` - A new version will be created. This will update `package.json` and `package-lock.json` automatically and create a commit. -7. Do a trial publish by running `npm publish --dry-run`. +6. Do a trial publish by running `npm publish --dry-run`. - No need to run any special build steps — the publish script will lint the source JavaScript and Sass files, and clean and re-build all assets before including them in the published package. - Consider: In the files listed, are there any that should or shouldn't be included? Does the version match what you expect? -8. If everything looks alright, continue with publishing by running `npm publish`. -9. Push your release branch to the GitHub repository and open a pull request. -10. Once approved and merged, create a new release on the [GitHub "Releases" page](https://github.com/18F/identity-style-guide/releases). +7. If everything looks alright, continue with publishing by running `npm publish`. +8. Push your release branch to the GitHub repository and open a pull request. +9. Once approved and merged, create a new release on the [GitHub "Releases" page](https://github.com/18F/identity-style-guide/releases). - Use `main` as the target. - The release version should match the version just published to `npm` (for example, `v2.1.5`). - Use the version name as the release title.