When release PR created from latest pre-release commit, message of "No changes from latest pre-release" appended to release notes, but most of the times additional release notes should be provided to CHANGELOG and other mediums instead.

With that in mind need to allow badabump expect on release notes message in cli args.

Mark all non-conventional commits as Other and do not break running badabump if for some reason there are some non-conventional commits in range between last release and current time.

Steps to reproduce:

• Commit: playpauseandstop/react-sadness@f977a5a
• Message: Create Dependabot config file
• Failed build: https://github.com/playpauseandstop/react-sadness/runs/3215252372?check_suite_focus=true

When current version is a pre-release there should be an ability to create final release PR even no changes available.

For example,

• Current release: 20.1.0b0
• badabump should change version to 20.1.0
• And add line of “No changes from last pre-release” into the changelog

TLDR: Seems like badabump doesn't properly handle version tags of pre-releases with multiple digits, such as v21.1.0a10

Got strange issues on running, python3 -m badabump.ci prepare_release "refs/tags/v21.1.0a10",

Traceback (most recent call last):
  File "/Users/playpauseandstop/.pyenv/versions/3.8.8/lib/python3.8/runpy.py", line 194, in _run_module_as_main
    return _run_code(code, main_globals, None,
  File "/Users/playpauseandstop/.pyenv/versions/3.8.8/lib/python3.8/runpy.py", line 87, in _run_code
    exec(code, run_globals)
  File "/Users/playpauseandstop/.pyenv/versions/3.8.8/lib/python3.8/site-packages/badabump/ci/__main__.py", line 5, in <module>
    raise SystemExit(main())
  File "/Users/playpauseandstop/.pyenv/versions/3.8.8/lib/python3.8/site-packages/badabump/cli/ci_app.py", line 113, in main
    return cast(int, args.func(args, config=config))
  File "/Users/playpauseandstop/.pyenv/versions/3.8.8/lib/python3.8/site-packages/badabump/cli/ci_app.py", line 52, in prepare_release
    version = Version.from_tag(tag_ref, config=config)
  File "/Users/playpauseandstop/.pyenv/versions/3.8.8/lib/python3.8/site-packages/badabump/versions/version.py", line 30, in from_tag
    return cls.parse(
  File "/Users/playpauseandstop/.pyenv/versions/3.8.8/lib/python3.8/site-packages/badabump/versions/version.py", line 79, in parse
    pre_release=pre_release.PreRelease.from_parsed_dict(
  File "/Users/playpauseandstop/.pyenv/versions/3.8.8/lib/python3.8/site-packages/badabump/versions/pre_release.py", line 73, in from_parsed_dict
    pre_release_type=guess_pre_release_type(
  File "/Users/playpauseandstop/.pyenv/versions/3.8.8/lib/python3.8/site-packages/badabump/versions/pre_release.py", line 120, in guess_pre_release_type
    return {
KeyError: 'a1'

Need to figure out where the problem and fix it to support pre-releases with multiple digits.

There is a situation when same project directory can have multiple projects as well as one repository can have multiple projects, need to find a way on how to support both of these cases.

As already done by black and others need to use tomli instead of toml for dealing with reading config from TOML files.

If BREAKING CHANGES: only happened in Other section it is hard to visually find them within Release Notes.

To fix this, need to move those BREAKING CHANGES: under the new Breaking Changes section to make them easy to observe. But do not move out those lines from Other section if there are any other Breaking Changes into Features / Fixes / Refactoring sections.

Need to improve ci_release.yml workflow to include footer link as below,

**Full Changelog:** https://github.com/<OWNER>/<REPO>/compare/<PREV_TAG_NAME>...<CURRENT_TAG_NAME>

As of now badabump understands only Issue: XXX footer issue references, but it should understands other issue references as,

• Closes: XXX
• Fixes: XXX
• Ref: XXX
• Relates: XXX

Need to ensure that following footers are ignored by default, when running badabump-ci prepare_release ...,

Co-authored-by: playpauseandstop <...>

At a moment Python 3.11 build failed at CI with weird git error, while all other Python versions run clean.

Need to investigate deeply and fix this issue.

If previous version is 20.6.0 badabump will prepare 21.7.0 release instead of 21.1.0. Need to fix the logic in CalVer update and ensure that any previous release for schema YYYY.MAJOR.MINOR like:

• 18.1.0
• 19.3.0-rc1
• 20.6.8

will result in 21.1.0 version if the year is changed.

Need to provide documentation for badabump CLI tool, how it works, how to setup GitHub Actions workflows, success stories, and reasoning why this tool exists.

Need to provide tests to cover all badabump usage scenarios,

• Running badabump for repository without tags
• Running badabump for repository with tag
• Running badabump-ci for parsing last commit
• Running badabump-ci for parsing tag info

https://github.blog/changelog/2022-10-11-github-actions-deprecating-save-state-and-set-output-commands/

Need to deprecate set-output in badabump outputs.

At a moment if commit message looks like,

fix(users): Change password policy

Do not expect user to put special character in their
passwords.

Issue: PROJ-123
Fixes: https://sentry.io/organizations/organization/project/123/

It will result in next CHANGELOG entry,

## Fixes

- [PROJ-123, https://sentry.io/organizations/organization/project/123/] Change password policy

which is not very useful as GitHub do not auto-link URLs.

With that in mind need to disable adding URLs from footer blocks by default, and allow to enable previous behaviour by setting,

[tool.badabump]
changelog_ignore_footer_urls = false

in pyproject.toml file.

If package name contains dashes, such as aiohttp-middlewares, but package itself contains underscores, like aiohttp_middlewares, badabump will not guess init file and skip version update there.

If git commits for changelog contain same commit messages, such as,

- chore: Sync common project files (#XYZ)
- feat: Shiny new feature
- chore: Sync common project files (#YZA)

need to join Sync common project files commit into one line,

- Sync common project files (#XYZ, #YZA)

And if the commits are completely same - leave only first one and do not duplicate lines in a changelog.

Related: playpauseandstop/aiohttp-middlewares#134

TODO:

• Do not duplicate same commit subjects in ChangeLog (done via #196)
• Merge commit subjects Same (#1) and Same (#2) into Same (#1, #2)

As GitHub release page now has fancy Contributors block, which automatically shown from release content it makes sense to include contributors into ChangeLog items and as result they will be included at GitHub release pages.

Right now only Features & Fixes grouped into, all other commits go into Other section, but it's good to have at least Refactor commits grouped, cause in many cases Refactor commits need to be highlighted in CHANGELOG files (and commits).

All revert commits should be grouped and placed under the separate section of Reverts at the end of version changelog.

And by default all "chore: X.Y.Z Release" revert commits should be ignored from changelog at all.

On top of that repository can configure to omit such commits from CHANGELOG altogether.

There are situations, when badabump bumps project to lower version than needed: for example when there is one commit of,

• build: Update to Python 3.10

badabump will bump 21.2.3 version to 21.2.4, but in reality it is needed to be bump to 21.3.0.

Need to define a way to pass an exact next version on invoking badabump, so it will make all the CHANGELOG changes and stuff, but for requested version, not for auto-generated.

Another nice feature to have is expecting on additional release notes to be passed to badabump. Using example above it would be nice to have a way to pass Ensure Python 3.10 support. line, which should be included to CHANGELOG.

Subj.

If release commit message contains single quote, release_tag workflow will wail as single quote passed non-escaped to git tag ....

At a moment badabump replaces current_version to next_version in entire data source, which might result in updating external dependencies, which has same version as a project.

Need to tighten rules for version replacement to ensure only expected lines has been updated.

Currently, if release commit contains backticks, they are not escaped and as result inner content does not go to release notes.

Need to escape backticks, to ensure that all inner content will properly published in release notes.

When repository does not contain tags and pyproject.toml or package.json contains pre-release version, need to put "Initial pre-release" into changelog file, even no --pre flag is passed.

Right now badabump puts proper pre-release note into changelog file only when --pre flag is passed.

Relates: #15

At a moment, if commit subject contains leading or trailing space, these spaces will be included in changelogs and release notes. This will lead prettier and some other pre-commit hooks to fail as they attempt to replace multiple spaces to single space.

To fix this need to strip leading and trailing spaces in commit subjects on reading commit messages from git repo.

If there is no versions released (no git tag available in repository) there should be an ability to create first release PR with badabump