generate changelog only from tags matching specific patterns

[bhelgs]

Description

It seems right now the changelog generator is capturing all tags, rather than just the tags matching the version pattern. It was mentioned in this TODO in the code.

Without filtering tags:

• A user might create a pre-release tag v2.27.0-alpha and then later come to find it in their changelog.
  • it seems they would have to delete the tag otherwise they see v2.26.0...v2.27.0-alpha...v2.27.0 rather than v2.26.0...v2.27.0
  • (see "Additional context" section for more info if necessary)
• It prevents users from having some sort of tagging practices unrelated to "release versions"
  • (see "Additional context" section for more info if necessary)

Possible Solution

1. Allow users to specify a custom tag format via configuration regex.

   [tool.commitizen]
   # tag_format = "v$major.$minor.$patch$prerelease" # already used by "bump" (nothing new proposed)
   tag_parser = "v[0-9]*\.[0-9]\.[0-9]*" # proposed: filter for "released" versions only.
                                                            # tag_parser mirrors tag_format used by bump.
   

2. Mimic current functionality by default (base commitizen):
   • match every tag by setting a default .* regex.

I believe this is an alternate solution to what was discussed on #364 and may be more extensible, for example:

• The user could just edit tag_parser if they want multiple changelogs with different parse criteria
  • avoids the creating custom CLI that was proposed here: #454
• Capture each field within the version for use in other parts of changelog module:
  • v(?P<major>[0-9]+)\.(?P<minor>[0-9]+)\.(?P<patch>[0-9]+)(?P<pre>[0-9A-Za-z-]?
• The user may have changed their versioning pattern at some point and the parser would allow for that:
  • (v[0-9.]*|release-[0-9.]*) (pattern matches v1.2.0 or release-1.2.0)

Additional context

A user may have created a pre-release tag not knowing it would eventually show up in their changelog:

## v2.27.0 (2022-05-16)
### Feat
- added another thing
## v2.27.0-alpha (2022-05-16)
### Feat
-  let it respect pre-commit reformats when bumping
## v2.26.0 (2022-05-14)
### Feat
- Add --allow-abort option

When they really wanted:

## v2.27.0 (2022-05-16)
### Feat
- added another thing
-  let it respect pre-commit reformats when bumping
## v2.26.0 (2022-05-14)
### Feat
- Add --allow-abort option

Additional context

Other examples of when a repository may have some custom tags:

• A team has a concept of "deliveries" that they are tagging.
• A team has a feature branch that they have some kind of custom version tags for:
  • feature_for_user_x_method_B_v1.0
  • feature_for_user_x_method_B_v1.1

[bhelgs]

Here is basically what the changes would look like to remove the TODO: https://github.com/bhelgs/commitizen/commit/1910b96b64a0b92b30efbe4abb7cdcfd67d2a08e#diff-9a66aca02ea7d31a58e52fc33fc6914dc724c8eb36ccb69f365f86ec3490497bL106

Would you like a PR?

[hongkongkiwi]

I would actually classify this as a bit of a bug, because I've already set my tag format in config: tag_format: v$version.

I would expect that cz changelog only looks at tags matching this format? instead of pulling in unrelated tags.

I like the provided solution, could dev's merge this?

[woile]

@bhelgs a PR would be more than welcome. I'll be back with commitizen by July, sorry for the slow response answer.