Pre-release v5

[stevenjmesser]

What

Provide pre-release(s?) of v5 before shipping the actual release. We need first to discuss:

• at which point it'd be relevant to pre-release
• in which way (actual npm pre-release or Github ones)

Why

v5 brings substantial changes to what we'll be shipping. Providing pre-releases will let people test early and give us feedback on anything that may need tweaking before the final release.

Who needs to work on this

Developers, Tech writers

Who needs to review this

Developers, Tech writers

Done when

Done when

Preview Give feedback

1. Plan the pre-release as a team #4029
   +0
   
2. Run an internal pre-release to npm #4228
   🚀 release +1
3. Review GitHub issues needing creation during pre-release process #4229
   +0
4. Plan briefing to let us do some light user research #4292
   +0
   
5. Contact people in other teams for interest in pairing #4293
   +0
   
6. Do the pairing #4294
   +0
   

   
7. Review results from the pairing #4295
   +0
8. Update bin/generate-npm-tag.sh script to pick the tag corresponding to pre-release #4396
   tooling 🚀 release +2
9. Provide pre-release branches with a 5.x version number #3661
   awaiting triage +1
10. Publish a -beta.1 pre-release with the fixes added so far #4418
    +0
11. Publish a -beta.2 pre-release with the latest round of fixes #4475
    🚀 release +1
    

Pre-release feedback

Preview Give feedback

1. Move private workspace packages to devDependencies #4391
   submitted by user 🐛 bug +2
2. Add CHANGELOG entry about <script> snippet #4392
   +0
3. Improve SupportError when document.body is not set #4394
   javascript 🐛 bug +2
4. Improve explanation for loading GOV.UK Frontend with type="module" in CHANGELOG #4436
   documentation +1
   
5. Discuss binding execution of initAll to the DOMContentLoaded event #4437
   javascript +1
6. Review accessibility of native <details> element #4474
   accessibility details +2
   
7. Document how people can install pre-releases #4476
   documentation +1
   
8. Investigate improvements for SupportError message #4477
   javascript +1
   

[romaricpascal]

A couple of options:

• Could we automatically build a pre-release branch for main after each merge (via a Github action)?
• Colin floated the possibility of pre-releasing PRs to Github's npm registry automatically so that each PR can be tested that way. This could include Github actions running against that published version (for testing for ex.).
• And there's of course the option to manually publish a pre-release package to npm

[colinrotherham]

When manually publishing a pre-release we'd typically publish to a GitHub branch

But we should consider npm publish --tag next for access to our "next" release alongside "latest":

npm install govuk-frontend@latest
npm install govuk-frontend@next

Along with the tag @latest @next we can use a “release candidate” version number:

Bump v4.7.0 to v5.0.0-rc.0

npm version premajor --preid rc --no-git-tag-version --workspace govuk-frontend

Bump v5.0.0-rc.0 to v5.0.0-rc.1

npm version prerelease --preid rc --no-git-tag-version --workspace govuk-frontend