Changelog generation should optionally consider a last release tag regex for comparison

[guilhermeblanco]

We adhere with semver and our versions are generally following a minor release cadence. This means we have v1.1.0, then v1.2.0, etc.
In rare scenarios, we are required to deploy hotfixes while the next minor is being implemented, so we require to deploy a v1.2.1. To do that, we create a branch from the tag v1.2, and we apply our hotfix via PR being merged. This builds a release with the change reference. After we verify and deploy, we then merge the changes into default branch.

However, at this point, all changes that were made to this point are now lost in the changelog, and only the hotfix merged change is listed. Here is an awesome drawing showing the problem:

        PR Merges      A  B  C   Hotfix merge to default branch
        |  |    |      |  |  |   |     
---o----o--o----o------o--o--o---o------------> default branch
   |            |               /
v1.1.0       v1.2.0            /
                 \-------o----o--------> v1.2
                         |    |
                     Hotfixes  \ v1.2.1 release tag

Whenever the v1.2 branch gets merged back to default branch, PR merges A, B and C are now lost in the changelog for the draft of v1.3.0.

Conceptually, it would be great if we could define a release reference mask to compare against the draft being built. I see in https://github.com/release-drafter/release-drafter/blob/master/lib/releases.js#L32 the last release can be optionally determined by target_commitsh, but idealy it could also use a RegExp against the release tag (ie. v[^\,]*\.[^\,]\.0) as a comparison for the last release, so that way it would see v1.2.0 as the previous release and would generate the changelog from that version instead of the v1.2.1, the culript of losing the changelog of PR merges A, B and C.

Please let me know if there is any more information I can provide to assist with this issue report.

Thanks,

[guilhermeblanco]

In my specific case, it is possible to rely on filter-by-commitish to work, so I am closing this issue

[antwan-flinkhub]

@guilhermeblanco wondering how filter-by-commitish solved your issue I'm facing the exact same issue
Thanks

[mkurz]

You might be interested in #656 (comment) and also #1061