CHANGELOG.md with pre-release versions

[lictw]

Is there an existing issue or pull request for this?

• I have searched the existing issues and pull requests

Feature description

I have pre-release rc.* tags and would like to generate CHANGELOG.md with them. Now, without any options pre-release tags considered like everything else, so I will have notes for rc.*, but when I release new version git-cliff will generate notes only from latest RC tag, not from latest stable tag.

For clarify, for tags 2.0, 2.1-rc.0, 2.1-rc.1, and 2.1 I want:
2.0 -> 2.1-rc.0
2.1-rc.0 -> 2.1-rc.1
2.0 -> 2.1

_{Also I don't understand use-cases of skip_tags option, can you explain? For ex. if it alpha, does it drop all commits from any matched prev. tag to obtained alpha tag, for what can I need this?)}

Desired solution

Separated logic for stable and pre-release tags.

Alternatives considered

Only manual approach with combinations of tag-pattern (include/exclude pre-release tags) (or ignore_tags, but it's 2 mostly repeatable configs, no CLI option) and --prepend option one by one from version to version, I can't find any way to generate all file with my requirements.

Additional context

No response

[orhun]

Hello!

Also I don't understand use-cases of skip_tags option, can you explain? For ex. if it alpha, does it drop all commits from any matched prev. tag to obtained alpha tag, for what can I need this?)

For example:

# regex for skipping tags
skip_tags = "beta|alpha"

# regex for ignoring tags
ignore_tags = "rc"

Consider this release history:

v0 -> v1-alpha -> v1-beta -> v1-rc.0 -> v1

• Commits for beta and alpha releases won't appear in the changelog.
• Commits for rc will appear under the most recent tag (v1)

So ignore_tags will move all of the commits contributing to those tags into the next non-ignored tags. Thus it also affects commits that themselves are not tagged.

Whereas skip_tags completely drops the tagged commits from processing but doesn't affect any other commits.

Let me know if this works for your use case and if there is anything else that I can help you with! 🐻

[lictw]

but doesn't affect any other commits

I re-tested it. In my case the generator drops ALL commits from latest "normal" tag to skipped, so they aren't appear in next changelog.

So for history bellow all highlighted with red commits aren't presented in changelog v2.0.0 -> v2.1.0-rc.0 when alpha tags are skipped, and I understand the option ignored_tags, I questioned about cases where this behavior can be required.

[lictw]

Thanks, I will re-test this behavior: I understood how this constructions work, I questioned about use-cases, but in my experience skip_tags also drop all commits before tagged/skipped commit (from prev. not skipped) that I will re-test.

But.. What about the main part of the issue? You closed it, but question about skip_tags use-cases was only a side-question)

[orhun]

But.. What about the main part of the issue?

If I understood correctly, you want to have the RC tags present in the changelog until there is a new stable release, correct?

Then this might work:

[git]
# regex for skipping tags
skip_tags = "beta|alpha"
# regex for ignoring tags
ignore_tags = "rc|v2.1.0|v2.1.1"

I'm not sure if I got your question correct, so please let me know with an example git history to further clarify things.

You closed it, but question about skip_tags use-cases was only a side-question

I converted the issue to a Q/A discussion which I think makes more sense 🐻

[lictw]

Nope, I want always have RC changelogs.

For clarify, for tags 2.0, 2.1-rc.0, 2.1-rc.1, and 2.1 I want:
2.0 -> 2.1-rc.0
2.1-rc.0 -> 2.1-rc.1
2.0 -> 2.1

Now the tool always does changelog from latest non-ignored tag, it doesn't matter is this tag stable or not, so it does changelog from latest RC tag in my example, not from latest stable.

I want changelog like this

Changelog

All notable changes to this project will be documented in this file.

v1.3.0 (2024-03-31)

🚀 Features

• foo
• bar
• baz

v1.3.0-rc.1 (2024-03-31)

🚀 Features

• baz

v1.3.0-rc.0 (2024-03-31)

🚀 Features

• foo
• bar

v1.2.4 (2024-03-31)

[orhun]

I think this use case has been made possible via recently added count_tags option. See #599