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

Compare releases agains previous release (skipping prerelease) #138

Open
burtek opened this issue Apr 12, 2024 · 3 comments
Open

Compare releases agains previous release (skipping prerelease) #138

burtek opened this issue Apr 12, 2024 · 3 comments
Labels
question Further information is requested

Comments

@burtek
Copy link

burtek commented Apr 12, 2024

Right now when I create a release after a pre-release, the release changelo only contains changes since the pre-release and the compare link in changelog points to diff between pre-release and this release.

I'd like to make releases always compare against last full release rather than prerelease.

Let's say I have versions 1.0.0, 1.1.0-alpha.1, 1.1.0-alpha.2 and 1.1.0.

I want the changelog to show:

  • for 1.1.0-alpha.1 - changes since 1.0.0 (as it works currently)
  • for 1.1.0-alpha.2 - changes since 1.1.0-alpha.1 (as it works currently)
  • for 1.1.0 - changes since 1.0.0 (including all changes from prereleases) and the compare link pointing to /compare/v1.0.0...v1.1.0

Is this possible now?

@burtek burtek added the question Further information is requested label Apr 12, 2024
@TimothyJones
Copy link
Member

I don't think this is currently possible without mucking about with multiple sets of tags (or renaming tags out of the way, which I don't think is a good idea).

If I had this use case once or twice, I would just delete the pre-release tags locally and then run commit-and-tag-version. If it was often, something more automated might be better

@burtek
Copy link
Author

burtek commented Apr 12, 2024

So for now I'm gonna make a script that removes prerelease tags, runs this library and pulls tags back from origin.

But I guess that's something that can possibly be implemented and end up being a PR here?

@TimothyJones
Copy link
Member

The rationale for which changes to accept is here - I feel like it fits, although I'm not sure that it would be easy to come up with a general case that doesn't make assumptions about how / when the tool is invoked. What do you think?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants