Skip to content

Improve support for monorepo using Conventional Commits scope #1215

@asaf

Description

@asaf

Feature Request

Description

Currently, Python Semantic Release does not support filtering commits by scopes ((pkg1), (pkg2)) in monorepos. This means that when multiple packages exist in a single repository, version bumps may happen incorrectly.

For example, given a monorepo with two packages: /packages/pkg1, /packages/pkg2

If a commit like:

feat(pkg1): Added new API feature

appears, pkg2 should not get a version bump, but currently, semantic-release does not support filtering commits by scope.

Use cases

  1. Monorepos with independent package versioning

    • Developers working on multiple packages in a single repository often want each package to be released separately.
    • Example: A commit feat(pkg1): Added logging should bump pkg1's version, but pkg2's version should remain unchanged.
  2. Scoped commit filtering for better release control

    • Some teams use commit scopes (feat(pkg1): ..., fix(pkg2): ...) to specifically indicate which package was modified.
    • Currently, semantic-release reads all commits, making it difficult to version packages separately in monorepos.

Possible implementation

  1. Introduce a commit_scope_filter option in pyproject.toml
[semantic_release.commit_parser_options]
minor_tags = ["feat"]
commit_scope_filter = "pkg1"
  • If set, semantic-release only considers commits with the matching scope.
  • If not set, semantic-release behaves as it does today (reading all commits).
  1. Modify commit parsing to respect the scope filter
  • When calculating the next version, ignore commits that do not match the specified commit_scope_filter.
  1. Extend semantic-release changelog to support scope filtering
semantic-release changelog --scope=pkg1

Alternative solutions

  • Using separate repositories for each package (not ideal for monorepos).
  • Manually filtering commits before running semantic-release per package.
  • Running semantic-release in isolated environments per package and limiting git log manually.

This feature would greatly improve monorepo support in semantic-release by ensuring that only relevant commits impact versioning for each package.

Best,
Asaf

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions