Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

add npm update step to release process #155

Merged
merged 2 commits into from
Jul 15, 2022
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
3 changes: 2 additions & 1 deletion CONTRIBUTING.md
Original file line number Diff line number Diff line change
Expand Up @@ -29,7 +29,8 @@ The `develop` branch is the development branch which means it contains the next
## Release instructions

1. Branch: Starting from `develop`, cut a release branch named `release/X.Y.Z` for your changes.
1. Version bump: Bump the version number in `insert-special-characters.php`, `readme.txt`, `package-lock.json`, and `package.json` if it does not already reflect the version being released.
1. Version bump: Bump the version number in `insert-special-characters.php`, `readme.txt`, and `package.json` if it does not already reflect the version being released.
1. Update packages: Run `npm update` so that `package-lock.json` gets updated from the version bump in `package.json` in the previous step as well as handle various available dependency updates.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm fine with this but any concerns here with introducing bugs from an updated dependency?

We normally lock our dependencies to minor releases (using the ^ syntax) and hopefully there aren't any breaking changes in a minor but there's a possibility here that we run npm update, it updates something that introduces a bug/regression/incompatible change.

Maybe we just add additional instructions to this step around doing some quick testing to ensure things still work? This will vary based on the plugin, basically you'd need to look at what dependencies and devDependencies we are loading and what those are used for and then test appropriately. Could just be tests around ensuring the plugin builds properly, could be more functional type tests.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah this will likely vary by plugin, but hopefully a combination of decent e2e tests and a manual check during the Test portion of the release process will catch any issue? Alternatively we could go back to Dependabot opening PRs for every minor bump in dependencies, but that felt overly chatty. Not really certain that I'm opinionated on best approach here besides wanting to keep things updated (but obviously still working in the plugin) with the least amount of mental gymnastics needed by a maintainer to stay on top of these changes.

1. Changelog: Add/update the changelog in `CHANGELOG.md` and `readme.txt`
1. Props: update `CREDITS.md` file with any new contributors, confirm maintainers are accurate
1. New files: Check to be sure any new files/paths that are unnecessary in the production version are included in `.distignore`.
Expand Down