googleapis / googleapis/release-please

Filter scopes

Open
#1,186 3 comments 3 reactions 1 assignee Claimed by @chingor13 View on GitHub
type: feature request
Dominant language
TypeScript
Stars
7.5k
Forks
588
Avg merge
12h 16m
Merged PRs (30d)
7

Description

**Is your feature request related to a problem? Please describe.**

Let's say I have some changes pending to be released. Then I realized there is a bug in one of the new unreleased features. So I fix it.

What should be the commit message type for that fix? It is definitely a fix, so the only commit type that makes sense is `fix`. But it's a fix of a bug that is not released, so I don't want that log to appear in the changelog (the next release will *not* fix that bug, because that bug didn't exist in the last release).

**Describe the solution you'd like**

1. I would like to use the `fix` type with a special `unreleased` "scope". Example: `fix(unreleased): blablabla`.
2. I'd like to configure release-please ignore all commits that have the unreleased scope.

Note that `release-please` would not know about the `unreleased` scope. That would be my own project-wide convention. I'd only tell release please to ignore some scopes.

This has the advantage to be a generic solution that can be applied to other needs. For example, if my repository contains multiple parts let's say `frontend` and `backend`. I may decide to exclude the `backend` scope from the changelog because I destinate the changelog to users of the frontend.

**Describe alternatives you've considered**

There could be a special footer, that tells what commit introduced the bug. Example:
```
fix: blablabla

bug-introduced-by: deadbeef
```

And then release-please would automatically choose to either include it in the changelog (if it fixes an already released bug) or exclude it (if it fixes a non-released bug).

But I think it is more complex to implement/maintain and is useful to fewer use cases.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.