Publishing Workflow

New releases

1. See the release docs for authoring new releases in the code repo.
2. After publishing the new release on github and npm:

   1. Update the uswds npm dependency with the following, where X.Y.Z is the new version:

      npm upgrade --save uswds@X.Y.Z
      # or with Yarn, upgrading within a major release
      yarn upgrade uswds

      Note: If you're upgrading to a new major release (e.g. from 1.x to 2.0.0) you'll need to specify the version number above, as in npm upgrade --save uswds@2.0.0.

   2. Create a release branch for the change, i.e. release-X.Y.Z, from develop. The branch name should exactly match that of the release branch in the code repo.

   3. Commit the changes to package.json (and, if it's committed, yarn.lock) to the release branch.

   4. File a pull request to merge the release branch to master, and tag a teammate to review it.

   5. Wait for Federalist to build, and make sure everything works!

      • Specifically, make sure that the new github release shows up on the list at /whats-new/releases/.

   6. Once your PR has been tested and approved by the reviewer, anyone may merge it.

      • Do not delete the release branch from github.

   7. Create a new pull request to merge the release commit from master to develop, and get somebody else to merge it ASAP.

News and updates

1. See the docs in the _posts directory for creating a new post.
2. Commit your post to a new branch with a name in the form update-{post-title}, where {post-name} is a short name for your post.
   • You may optionally prefix the branch with your initials, e.g. ms-update-announce-performance if Marco were writing an update on our new performance guide.
3. Submit a pull request to merge your branch, select a reviewer (or two), and let them know what you'd like them to review.
4. The reviewer may merge the PR after approving it, or the submitter may do so after the approval is submitted.

Other site-related changes

1. Propose changes in a pull request, and tag a reviewer. If you're looking for specific feedback, include that in the pull request description field.

2. Reviewers should ensure that the changes are visible and work as expected on the Federalist preview. If there's no preview link in the PR description, you can add one at the top with this template, replacing {BRANCH} with the PR branch name:

   ### [:sunglasses: Preview on Federalist](https://federalist.fr.cloud.gov/preview/18f/web-design-standards-docs/{BRANCH}/)

   Note: Federalist's staging environment pushes status messages back to github PRs. As soon as the feature that enables this is deployed to Federalist's production environment, we should remove this repo from Federalist staging to ensure that the instances aren't stomping on each other.

3. After approving, anyone may merge the PR, but it's best if the reviewer does it.

4. After merging, be sure to delete the branch from github. (You can always restore it, or the committer can push it back up.)