Change Request: `release-please` should create release only for certain tags

[mdjermanovic]

ESLint version

N/A

What problem do you want to solve?

Currently, in all repositories where we use release-please, it's configured to generate/update the release PR on any commit we push to the main branch, regardless of the commit tag.

The commit tags we're using are:

• build
• chore
• ci
• docs
• feat
• fix
• perf
• refactor
• test

The problem is that not all kinds of commits warrant releasing a new version of the package. For example, if the only change we made since the last release was adding more tests, releasing a new version of the package does not benefit anyone. When deciding which packages to publish, we always need to review the commit list for each. It would be much easier for us if release-please would be generating release PRs only when there's a change we'd like to release.

What do you think is the correct solution?

Configure release-please to generate/update release PRs only for certain commit tags and review our policies for choosing tags for particular changes.

---

The tags that I believe we would certainly like to release a new version of the package for are:

• docs - to update README on npm
• feat
• fix
• perf

Then, there are changes that shouldn't be observable to end users but are affecting (or may affect) production code so we might want to release a new version to see if there are any issues as early as possible:

• build
• refactor

The tags that I believe we would not like to release a new version of the package for are:

• ci
• test

So above are 6 tags that I think release-please should generate/update the release PR for, and 2 tags that I don't think it should.

---

The remaining one is chore.

Per our policies, chore should be used "for changes that aren’t user-facing". Like, for example, fixing a typo in a test file. So, by the definition, these changes shouldn't warrant a new release.

But so far we have used this tag for changes that are user-facing, notably:

• Small changes in production code - I think we should be more strict here and always mark these changes as refactor.
• Updating dependencies - new versions of production dependencies may cause changes in the way our package works, so I think we should discuss whether we want to keep using chore for these changes or maybe introduce a new tag.

Participation

• I am willing to submit a pull request for this change.

Additional comments

No response

[nzakas]

The tags that I believe we would certainly like to release a new version of the package for are:

• docs - to update README on npm

• feat

• fix

• perf

I don't think we need docs. The case of needing to update the README on npm is an edge case, and when needed, I think it's fine to use fix to indicate that it's important to get fixed and published to users.

I also don't think build or refactor should trigger a release. I'd like us to get into the habit of just thinking of feat and fix as releasable artifacts because it indicates we are either adding something new or fixing something (perf being a special case).

[mdjermanovic]

Okay, so to summarize, only these three tags would trigger a release:

• feat
• fix
• perf

We'd continue using tags as before, with an exception: If we think that a change should trigger a release, but the tag we usually use for that kind of change is not one of the three above, we'd tag it as fix. An example is the mentioned README. Another example would be a dependency upgrade that we know fixes a bug that affects our package, in which case we'd tag it as fix instead of chore.

Does this sound good?

[nzakas]

Sound good to me. @fasttime what do you think?

[fasttime]

Okay, so to summarize, only these three tags would trigger a release:
* feat
* fix
* perf

Sounds good! Just to state the obvious, the tags will be the same for breaking changes as well (I think I've only seen feat! and fix! being used in practice).