Thanks a lot for this @dhensby

I have nom publishing access but I'd like to limit this only to the master branch so new releases are definitely reviewed beforehand by at least two of us. What do you think?

By default the release process won't work unless it's in a list of the default branches (master, next, and then N.x for changes to other versions). We can limit this to just master either in the release config or in the GH workflow (or both).

Ok then we can leverage npm tags so everything on next is also tagged @next (like alpha beta release candidate) and not auto installed by users while releases on master can be tagged @latest so they are installable without explicit version pinning

Yep - that's how it works "out of the box" 👍

@dhensby I just merged some dependabot dev-dependencies. Would these kinds of merges be ignored by your current PR?

I just merged some dependabot dev-dependencies. Would these kinds of merges be ignored by your current PR?

No; they are flagged as build: or sometimes chore(deps): commits that don't trigger releases. Also, if you use @dependabot merge command, the CI is run in reduced-privilege mode which means that the runs don't have access to the secrets and so they can't be used to perform releases.

In regard to dependencies, our version constraints should be permissive enough that any upstream consumer can be responsible for upgrading any packages that have vulnerabilities or bugs; if we start to depend on new major versions of dependencies that form part of our outward facing APIs (I don't think they do), then we should probably manually update them with at least minor and maybe major change releases.