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: feat: pre-release seperated changelog #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