From 6968c559a5ebd075491eec8bbba4d05ee63d6e6b Mon Sep 17 00:00:00 2001 From: Vanita Barrett Date: Fri, 20 May 2022 14:20:31 +0100 Subject: [PATCH] WIP --- .../publishing-from-a-support-branch.md | 32 +++++++++++-------- 1 file changed, 19 insertions(+), 13 deletions(-) diff --git a/docs/releasing/publishing-from-a-support-branch.md b/docs/releasing/publishing-from-a-support-branch.md index 8342477413..d39094d01e 100644 --- a/docs/releasing/publishing-from-a-support-branch.md +++ b/docs/releasing/publishing-from-a-support-branch.md @@ -1,11 +1,10 @@ # Publishing from a support branch -This document is for GOV.UK Design System developers who need to publish a support branch of GOV.UK Frontend when the `main` branch contains unreleasable changes. For example, you might need to release a fix as part of a: +This document is for GOV.UK Design System developers who need to publish a support branch of GOV.UK Frontend. For example, you might need to release a fix as part of a: - patch release, after the team has started to merge changes for a new feature release into the `main` branch - for example, a 3.14.x release once we've started merging changes for 3.15.0 -- release, after the team has started to merge changes for a new breaking release into the `main` branch - for example, a 3x.x release once we've started merging changes for 4.0.0 - -Do not use this document to release changes for previous major releases. We have not tested the document in this scenario, and extra work would be needed to tell npm not to mark the release as the 'latest'. +- release, after the team has started to merge changes for a new breaking release into the `main` branch - for example, a 3.x.x release once we've started merging changes for 4.0.0 +- release for a previous major version - for example, a 4.x.x release after we've released 5.0.0 If you want to publish the `main` branch for GOV.UK Frontend, [follow the steps in Publishing GOV.UK Frontend](/docs/releasing/publishing.md). @@ -55,7 +54,7 @@ Note: Before you go on annual leave, tell the delivery manager who will be looki ### Change the code -1. To check out the support branch for the current major release, run `git checkout support/.x`. If the branch does not exist, follow these steps to create it: +1. Find out which major version this release will be targeting, for example: if you're releasing v4.x.x, the major version is version 4. To check out the support branch for that major version, run `git checkout support/.x`. If the branch does not exist, follow these steps to create it: - make sure you have all tags locally by running `git fetch --all --tags --prune` - run `git checkout tags/v -b support/.x` - for example, `git checkout tags/v3.9.1 -b support/3.x` @@ -64,7 +63,7 @@ Note: Before you go on annual leave, tell the delivery manager who will be looki 3. Push the support branch to GitHub. The branch will automatically have branch protection rules applied. -4. To fix the issue, create a new branch (for example, `git checkout -b fix-the-thing`) from the `support/.x` branch. +4. Create a new branch for your code changes (for example, `git checkout -b fix-the-thing`) from the `support/.x` branch. 5. Run `npm install` to make sure you have the latest dependencies installed. @@ -72,13 +71,13 @@ Note: Before you go on annual leave, tell the delivery manager who will be looki 7. Update the changelog with details of the fix. -8. Commit your changes, then push your new branch (see step 4) to GitHub and raise a pull request, with `support/.x` as the base branch to merge into. +8. Commit your changes, then push your new branch (see step 4) to GitHub and raise a pull request, with `support/.x` as the base branch to merge into. -9. Once a developer approves the pull request, merge it into `support/.x`. It’s usually a developer who reviews the pull request, but sometimes pull requests need an extra review from another role. For example, if the pull request involves a design change, you may need a review from a designer. +9. Once a developer approves the pull request, merge it into `support/.x`. It’s usually a developer who reviews the pull request, but sometimes pull requests need an extra review from another role. For example, if the pull request involves a design change, you may need a review from a designer. ### Build a new release -1. Check out `support/.x`. +1. Check out `support/.x`. 2. Create and check out a new branch, `support-release-[version-number]`. The version number of the new release depends on the type of release. New features correspond to a minor (X.1.X) change - for example, '3.14.0 (Feature release)'. Fixes correspond to a patch (X.X.1) change - for example, '3.13.1 (Patch release)'. In either case, refer to the previous release of that kind, and give the new release the logical next number. To learn more about our versioning, see our [guidance on updating the changelog](/docs/contributing/versioning.md#updating-changelog). @@ -100,17 +99,24 @@ Note: Before you go on annual leave, tell the delivery manager who will be looki You will now be prompted to continue or cancel. -9. Raise a pull request, with `support/.x` as the base branch to merge into. +9. Raise a pull request, with `support/.x` as the base branch to merge into. -10. Once a developer approves the pull request, merge it into `support/.x`. +10. Once a developer approves the pull request, merge it into `support/.x`. ### Publish the release to npm -1. Check out `support/.x` and pull the latest changes. +1. Check out `support/.x` and pull the latest changes. 2. Sign in to npm (`npm login`), using the npm/govuk-patterns-and-tools team [credentials](https://github.com/alphagov/design-system-team-credentials/tree/main/npm/govuk-patterns-and-tools). -3. Run `npm run publish-release`, which will prompt you to either continue or cancel. Enter `y` to continue. +3. Run `npm run publish-release`, which will prompt you to check whether the NPM tag looks as expected. + + If you're following these instructions, it's likely that you're publishing an out-of-order release which should + *not* be tagged as the 'latest' release on NPM. In this scenario, + + Enter 'y' to continue. If you think the tag should be different, enter `N` to have the option to set your own NPM tag. + +Run `npm run publish-release`, which will prompt you to either continue or cancel. Enter `y` to continue. 4. View the created tag in the [GitHub interface](https://github.com/alphagov/govuk-frontend/releases) as follows: