Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update version regex #47

Merged
merged 2 commits into from
May 10, 2023
Merged

Conversation

kmsquire
Copy link
Contributor

@kmsquire kmsquire commented May 8, 2023

For repositories which mark versions with a v before the version
numbers, the v needs to be included in the captured version from the
changelog, or we won't find a matching version for filtering out already
added entries, and they will be duplicated.

Also check if the latest version tag is already part of the changelog.

@pawamoy
Copy link
Owner

pawamoy commented May 9, 2023

Also check if the latest version tag is already part of the changelog.

Can you elaborate on this? I'm not sure to understand the usefulness of this change.

Could you also split the PR in two, since there's a fix and a feat? Thanks!

@kmsquire
Copy link
Contributor Author

kmsquire commented May 9, 2023

Also check if the latest version tag is already part of the changelog.

Can you elaborate on this? I'm not sure to understand the usefulness of this change.

Sorry I didn't do that before!

Without this (or some equivalent change), running git-changelog twice without tagging results in a duplication of the full changelog. So I guess it's actually a fix.

Let's say that running git-changelog the first time adds a changelog section for 3.7.1 (which would be the next tag).

For the second run, latest_release (here) is 3.7.1.

But in _unreleased() (here), the latest version doesn't have a tag, only a planned_tag, and the next version in versions has tag 3.7.0.

So none of the version tags match 3.7.1, all lines are considered "unreleased", and the full changelog is then inserted into the file.

There are other possible fixes. For example, we could instead update _unreleased to check version.planned_tag in addition to version.tag. But, if someone is running git-changelog twice without tagging, it's possible that they have added more commits, in which case they'll want to overwrite the last section.

I felt the fix here was the easiest, and the user can then decide what to do. (I do need to change the tag from feat to fix. Done.)

Given this, do you

  • want a different fix?
  • still want this PR split into two PRs?

@kmsquire kmsquire force-pushed the feature/update-version-regex branch 2 times, most recently from a28f04e to 5697cd6 Compare May 9, 2023 16:04
@pawamoy
Copy link
Owner

pawamoy commented May 9, 2023

Thanks, that makes sense! I myself never run git-changelog twice (I only run it once I'm ready to tag, I have a script that automates that), so I never noticed this issue.

One last thing then: could you add some tests please? 🙏

@kmsquire kmsquire force-pushed the feature/update-version-regex branch from 5697cd6 to 895ec3b Compare May 10, 2023 00:05
@kmsquire
Copy link
Contributor Author

Okay, added tests to each commit.

@kmsquire kmsquire force-pushed the feature/update-version-regex branch from 895ec3b to 4147b0c Compare May 10, 2023 14:42
@kmsquire
Copy link
Contributor Author

And I fixed the code-quality checks.

For repositories which mark versions with a `v` before the version
numbers, the `v` needs to be included in the captured version from the
changelog, or we won't find a matching version for filtering out already
added entries, and they will be duplicated.
Previously, if git-changelog was run twice with bump_latest=True and
without tagging a new version in between, the full changelog would
be duplicated and written out.  This is because the latest version
in the CHANGELOG would not match any existing version tags, so no
lines would be filtered out before inserting the changelog into the file.
@kmsquire kmsquire force-pushed the feature/update-version-regex branch from 4147b0c to f1060ad Compare May 10, 2023 14:47
Copy link
Owner

@pawamoy pawamoy left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perfect! Thanks a lot!

@pawamoy pawamoy merged commit 1fad8a8 into pawamoy:master May 10, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants