[changelog] Generate changelog from issues and / or pull requests

[knutwannheden]

Is your feature request related to a problem? Please describe.
Generating the changelog / release notes from the commits is a very universal approach and simplifies a lot of things. But for platforms like GitHub and GitLab I think it would make sense to allow generating the release notes from a list of closed issues and / or merged PRs (aka MRs in GitLab) since the last release. This offers the advantage (YMMV...) that:

• the issue (or PR) description can be modified "after the fact", so that the issue / PR can be recategorized when necessary (e.g. by adjusting the labels)
• a issue / PR can be declared as breaking after the fact (this is basically the same as the bullet above)
• the commit messages don't need to follow strict conventions (again, YMMV)

I think a lot of GitHub projects already somehow automatically generate the release notes based on issue / PR queries. Examples that come to mind are Quarkus and HashiCorp repos like Terraform.

I suppose the actual list of issues / PRs that comprise a release largely depends on the project's release strategy and how they organize their issues using milestones (in GitHub) and tags.

Describe the solution you'd like
I don't know JReleaser very well, so I can't really comment on this yet. I suppose that it should somehow be possible, however, to generate the changelog based on some issue and / or PR (MR) query for platforms like GitHub and GitLab and then extract the title, description, labels, milestone from there to drive the changelog generation. The user would have to supply a query or query template and of course also the details required to categorize the issues / PRs.

Describe alternatives you've considered
If manual workarounds exist which still leverage JReleaser, then I am very interested!

[aalmiray]

@knutwannheden thank you for the suggestion. This particular feature has been proposed a few times but we decided to wait after 1.0.0 to tackle it. Now is a good time to discuss ideas and implement it 😄

While you wait, I can recommend you release-drafter which served as inspiration for JReleaser's changelog capabilities https://github.com/marketplace/actions/release-drafter

[knutwannheden]

Thanks for the pointer. I went through your open issues, but couldn't find anything similar to this issue. Feel free to close it, if you already track this elsewhere.

[aalmiray]

Oh no, I explained myself badly. The idea has been discussed somewhere else and we were missing a ticket to track it. Thank you for opening a ticket for it 😅

[lppedd]

Hey there!
Any plan to integrate this? If not, is there any way I can customize the changelog behavior using the Maven plugin?

[aalmiray]

JReleaser already supports generating a changelog using Github's native release notes feature. We don't [yet] support custom changelog generation based on issues/PRs/MRs as we do with commit messages.

There are several ways to customize the changelog based on commit messages https://jreleaser.org/guide/latest/reference/release/changelog.html

[lppedd]

@aalmiray currently our releases' notes, published in GitHub Enterprise 3.4.5, are handled through GitHub's defaults (a list of merged PRs between tags). Seems like I can give it a go then. Thanks!

[aalmiray]

Use the releaseNotes property of the Github releaser https://jreleaser.org/guide/latest/reference/release/github.html

[zakkak]

As discussed in graalvm/mandrel-packaging#350 (comment) to replicate the current release notes used in Mandrel releases we rely on this feature being implemented. I am willing to give it a try, but will need some guidance (and I might need to drop the effort if it turns out too time consuming).

Describe the solution you'd like:

At a bare minimum it looks like we would need a new option to instruct JReleaser to use PRs (and issues at some point?) instead of commits. As a second step we might also need to add an option to filter PRs (or issues) based on the milestone.

As the end user I would like to be able to use a configuration like the following:

changelog:
  formatted: ALWAYS
  contentTemplate: ./changelog.tpl
  skipMergeCommits: true
  usePRsInsteadOfCommits: true     # <--------- new option
  includeMilestones:               # <--------- new option
    - mandrel-23.0.0.0-Final
  excludeMilestones:               # <--------- new option (not sure what would be the use case of this TBH)
    - non-release-milestone
  includeLabels:
    - backport
    - release/noteworthy-feature
  categories:
    - title: 'Noteworthy'
      # Used for identifying the category
      key: 'noteworthy'
      labels:
        - 'release/noteworthy-feature'
      order: 1
    - title: 'Backports'
      key: 'backport'
      labels:
        - 'backport'
      order: 2

[aalmiray]

This is a good start, though I'd suggest adding a new section to changelog instead of 3 properties at the same level as existing ones.

Also, there might be some that would like to parse both commits and remote PR/Issues thus this option should not be exclusive (PRsInsteadOfCommits) but rather an opt-in with some sort of tristate enum include with NO, YES, EXCLUSIVELY. This new section also contains includedMilestones (assumes the current one based on patterns) and excludedMilestones (empty by default).