fix(bump): fix the issue that changelog_merge_prerelease not working on cz bump

[zimmermannJakob]

Description

This PR solves issue #1694.

Checklist

• I have read the contributing guidelines

Code Changes

• Add test cases to all the changes you introduce
• 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)
• Manually test the changes:
  • Verify the feature/bug fix works as expected in real-world scenarios
  • Test edge cases and error conditions (I thought about breaking changes and starting an empty changelog with prereleases.)
  • Ensure backward compatibility is maintained
  • 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]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 97.95%. Comparing base (193859b) to head (67cccef).
⚠️ Report is 3 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #1700      +/-   ##
==========================================
+ Coverage   97.93%   97.95%   +0.02%     
==========================================
  Files          60       60              
  Lines        2611     2646      +35     
==========================================
+ Hits         2557     2592      +35     
  Misses         54       54              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[woile]

Very nice, thanks!

[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.

[bearomorphism]

Changing the target branch to master to prevent the PR from auto closing. I think this PR is ready to merge but need rebasing.

[bearomorphism]

Hi @zimmermannJakob ,

Could you help to resolve the pipeline failure? Thanks!

[zimmermannJakob]

Hi @bearomorphism!
Thank you for your patience. I updated this PR.

[bearomorphism]

Thanks!