fix(1694): changelog_merge_prerelease not working on cz bump

[zimmermannJakob]

Description

This PR solves issue #1694. This PR is still in draft, as I want to check whether the changes make sense conceptually and manual tests are still pending.

Checklist

• [x] I have read the contributing guidelines

Code Changes

• [x] Add test cases to all the changes you introduce
• [x] Run poetry all locally to ensure this change passes linter check and tests (Some error out on mac. I will investigate if they fail in ci)
• [x] Manually test the changes:
  • [x] Verify the feature/bug fix works as expected in real-world scenarios
  • [x] Test edge cases and error conditions (I thought about breaking changes and starting an empty changelog with prereleases.)
  • [x] Ensure backward compatibility is maintained
  • [x] Document any manual testing steps performed ~~- [ ] Update the documentation for the changes~~ (I do not think this applies. It works now as documented.)

~~### Documentation Changes~~

~~- [ ] Run poetry doc locally to ensure the documentation pages renders correctly~~ ~~- [ ] Check and fix any broken links (internal or external) in the documentation~~

When running poetry doc, any broken internal documentation links will be reported in the console output like this:

INFO    -  Doc file 'config.md' contains a link 'commands/bump.md#-post_bump_hooks', but the doc 'commands/bump.md' does not contain an anchor '#-post_bump_hooks'.

Expected Behavior

See issue #1694.

Steps to Test This Pull Request

1. build the changes on the branch. poetry build.
2. Take the resulting .wheel file from dist/
3. Install the file in a separate python environment:

• python3 -m venv .venv && source .venv/bin/activate
• verify env: which pip
• pip install commitizen-4.10.0-py3-none-any.whl

4. Go through the steps in the issue description and try reproducing the bug.

Additional Context

~~Known issue: When the changelog only contains pre-releases, the old behavior can still be observed.~~ (Fixed)

[codecov[bot]]

Codecov Report

:white_check_mark: All modified and coverable lines are covered by tests. :white_check_mark: Project coverage is 97.87%. Comparing base (2072f8e) to head (976a55c).

Additional details and impacted files

@@             Coverage Diff             @@
##           v4-11-0    #1700      +/-   ##
===========================================
+ Coverage    97.84%   97.87%   +0.02%     
===========================================
  Files           60       60              
  Lines         2604     2639      +35     
===========================================
+ Hits          2548     2583      +35     
  Misses          56       56              

Flag	Coverage Δ
unittests	97.87% <100.00%> (+0.02%)	:arrow_up:

Flags with carried forward coverage won't be shown. Click here to find out more.

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

:rocket: New features to boost your workflow:

• :snowflake: Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[zimmermannJakob]

@woile @bearomorphism Thank you for your reviews! @bearomorphism I applied your suggestions, but left the conversations open for you to verify. Where I disagreed with a suggestion, I stated why.

[bearomorphism]

The latest commit should not be chore. I'd suggest you to rebase the commits and adjust the commit messages, so the commit history will be cleaner after merging

[bearomorphism]

I believe there is a way to mock the datetime in your new tests

[bearomorphism]

I remember git commit timestamp can be specified

Thanks!🙏

[zimmermannJakob]

@bearomorphism Thanks again for the review!

I believe there is a way to mock the datetime in your new tests

I used freezegun to set a fixed time.

I'd suggest you to rebase the commits and adjust the commit messages, so the commit history will be cleaner after merging

I tried that, but it shows a large diff now. Locally, if I do git diff upstream/master I see only my changes (changes.txt), so I am not sure why it shows the diff here on the PR. I used git reset --soft HEAD~7 to squash the commits. What did I do wrong? Any help is appreciated.

[bearomorphism]

@zimmermannJakob could you try to rebase to v4-11-0? Thanks.

[zimmermannJakob]

@bearomorphism Thank you, the diff looks good now! Just out of curiosity, do you know what the issue was? What is the etiquette surrounding open discussions? Should I close them if I deem them addressed, or do you close them as the creator of the discussion?

Anyway, the PR is good to go from my side.

[bearomorphism]

What is the etiquette surrounding open discussions? Should I close them if I deem them addressed, or do you close them as the creator of the discussion?

I would say it depends. I think PR creators can close the discussion themselves once they think the issue is resolved, but I also have seen in some cultures it's the reviewers closing the discussion.

Another option is to simply reply "fixed", but there are also people think it looks verbose if under every discussion there is a "fixed" comment.