How do I ignore pre-releases when generating a release changelog?

[SeraphCoding]

Hello,

in my hypothetical scenario I've got 2 proper releases and a bunch of pre-releases.

• v1.0.0
• v2.0.0-prerelease.0
• v2.0.0-prerelease.1
• v2.0.0-prerelease.2
• v2.0.0 (not yet tagged, no changelog generated, etc.)

When releasing v2.0.0 I'd like to include all the changes from the releases between the last major and this one.
Without the workaround mentioned below, cooking up a release locally only gives me the changes between the last pre-release and now. Which makes sense. Though doesn't suit the needs I've got.

The current solution is to delete all pre-release tags locally, release v2 locally. pull the missing tags again from the remote and push the v2 release.

This is quite hacky. It would be a lot nicer, if I could just specify to ignore all pre-releases between v1 and v2 via some flag and instead generate the changelog as though v2 followed v1 directly.
Is that possible? I couldn't find anything in the documentation to facilitate this.

[TimothyJones]

I'm open to supporting something like this, but it might be hard to do this generically.

There are many different approaches to pre-releases- supporting the specific workflow for one repository might not work for others. One of the main reasons for pre-releases is to have a back-and-forth on potential features, where a changelog generated between major tags would be misleading or contradictory (in addition to the many repositories which don't have notes for their pre-release versions).

It might be worth adding a note to the readme about good ways to do pre-releases, though - eg, using branches is a good way to generate pre-release tags without muddying the main release line.

[SeraphCoding]

A note like that would be very helpful indeed, as it could help people like myself implicitly understand that the way they are doing releases can be improved 😄