feat: add option to hide commits

[roggervalf]

it could be helpful to hide some commits, similar to commit-analyzer, but these commits should not appeared in our release notes some issues that can be related https://github.com/semantic-release/release-notes-generator/issues/153

[travi]

@roggervalf i think you are getting ahead of yourself with this PR. you've implemented a new option without making your use case clear. we are very hesitant to add more options to maintain over time and make clear to our users. as highlighted in our contributing guidelines, it is best to request features like this and convince the maintainers of the value before investing effort into an implementation.

since we've started with an implementation, we need to take a step back to make your intended use case clear and try to understand if it aligns with the goals of the project. you are welcome to include those details in this thread, but again, we are very hesitant to add more options, so it would need to be a very strong case for us to move forward with this sort of request.

[roggervalf]

@roggervalf i think you are getting ahead of yourself with this PR. you've implemented a new option without making your use case clear. we are very hesitant to add more options to maintain over time and make clear to our users. as highlighted in our contributing guidelines, it is best to request features like this and convince the maintainers of the value before investing effort into an implementation.

since we've started with an implementation, we need to take a step back to make your intended use case clear and try to understand if it aligns with the goals of the project. you are welcome to include those details in this thread, but again, we are very hesitant to add more options, so it would need to be a very strong case for us to move forward with this sort of request.

oh, I'm really sorry, I might read that before. Let me complete my pr description: Basically I'm working on a monorepo where my team maintains more than 1 package (in our case 2 packages for now) and we are using semantic-release for publishing. We are using "@semantic-release/commit-analyzer" so if we make changes on only one of those packages we don't want to release a new version on both packages only on the one affected, so we use releaseRules for this case with release option as false and a message expression only for the package that we want to avoid for that specific change:

        {
          "releaseRules": [
            {
              "message": "*\\[identifier\\]*",
              "release": false
            }
          ]
        }

this is working good on the release process, but on the other side, we are generating release notes, here we don't have a way to filter the commits as we do in commit-analyzer (as reference), so this pr is handling the same logic that is in commit-analyzer, so we can filter those commits that are not related to the affected package, our commits contains specific expressions as identifier to filter our commits as the rule above. I wonder if it could be feasible to have same functionality on release-notes-generator to match the same behavior.

[travi]

sorry that it has taken so long to get back to you about this.

Basically I'm working on a monorepo where my team maintains more than 1 package (in our case 2 packages for now) and we are using semantic-release for publishing.

i have to start out with the context that i imagine you've likely seen in other responses in other issues and PRs. semantic-release does not officially support monorepos. the sort of use case that you are describing is a good example of why. these scenarios do not exist when using in a repo that isolates a single package, which is the officially supported use case.

if we make changes on only one of those packages we don't want to release a new version on both packages only on the one affected

i appreciate this desire and agree that still versioning your packages independently is the correct way to still communicate impact to your consumers with semantic versioning.

unfortunately, i cannot justify accepting this change since it simply is not in line with the goals of the project. while this might be a workaround that could enable your use case, the option would not need to exist for supported use cases. that means it becomes an additional option that we would need to maintain over time for a use case that we do not officially support.

if we would add official support for monorepo use cases in the future, we would want to approach it in a way that these types of details are built into the chosen workflow automatically rather than leaving a bunch of knobs that our users need to find and figure out how to make work together on their own.

instead of making this work with raw semantic-release, you might have better luck with with extensions that have been created by the community. one that i've used with success in the past is semantic-release-monorepo, but i know it is currently a few major versions behind semantic-release because of handling the esm changes we made somewhat recently.