changelog --subdirectory

Description

Allow to filter commits affecting only a subdirectory.

Possible Solution

cz changelog --subdirectory my_module --file-name my_module/CHANGELOG.md

Additional context

I’m considering proposing this for @OCA. There, repositories mostly are split into modules, where each one of them has its own readme and (maybe) changelog.

So, when autogenerating changelogs, only commits affecting the module should be taken into account. AFAICS that wouldn’t be possible currently.

git format-patch allows such filtering (example recipe – for other purposes). It would be nice if commitizen could leverage that and make this a reality.

[woile]

It’s a possibility, but I don’t think semver and pep-0440 would be able to parse a tag like that.

I get:

InvalidVersion: Invalid version: 'submodule-v1.2.3'

From my understanding the way is to add the metadata at the end with a + sign. This way, users would be able to choose to also publish those tags as a valid semver or pep-0440. This, I think is important, because even something as a helm chart requires a valid semver for example (even pep-0440 breaks when adding a rc).

[woile]

Regarding this, for my original purpose when opening this issue, we don’t use tags on those repositories.

I foresee some issues with the changelog generation in this situations, as we do use tags to generate the changelog itself.

Instead, the version is kept in a metadata file in the repo, which is specific for each module (subdirectory).

I prefer this alternative, to avoid maintaining a lot of .cz.toml files.

This seems like a contradiction to me. Instead of having one cz.toml per project or 1 cz.toml, you have 1 top cz.toml + 1 metadatafile. And I really don’t want users to have 2 different files. A minimal .cz.toml would look like:

[tool.commitizen]
version = "2.18.0"
workspace = true

I don’t think it’s such a heavy burden vs a metadata file like:

2.18.0

I think eventually, support for the members could be introduced, and then cz bump could navigate the members. But having a .cz.toml per package enables also some extra benefits, like disabling changelog for specific package, using a different changelog file, different conventions per package, and all of this by just keeping the settings.