🆕 GitHub Releases UI Refresh and Automatically Generated Release notes are in Public Beta

[MylesBorins]

We’ve just released a significant update to GitHub Releases including a complete refresh of the UI experience and the ability to automatically generate release notes at the click of a button (or the call of an API).

Now, when you automatically generate notes for a release, we’ll identify all of the pull requests that are part of that release and create a summary for you, as well as recognize first-time contributors to your project. This can be done in our editor when manually creating a release or through the API. Check out how to get started in our docs.

This new UI is not yet turned on by default, so if you’re interested in using it head over to the Feature Preview to enable it on your repositories. You can read more about the updates to GitHub Releases in our blog post.

Please let us know if you have any questions, feedback, or run into any issues with the new experience. Can’t wait to hear from y’all.

[nrlquaker]

Is it possible to show full release notes on the latest release like it was before?

[aleksey-hoffman]

@MylesBorins good job guys!
Any progress on the latest release auto expansion (read more section)?

[ann0see]

Why not make it possible to use a #readmore# tag which can optionally be added somewhere in the release notes which would - if set - show everything until the tag and hide everything else after a "Read more" link?

[MylesBorins]

We are going to move forward with

• making the latest release show the full release notes
• read more expanding in place rather than forwarding to another page
• an attribute to expand all cards by default
• search result expanded by default

The combination of these changes seem like they find the balance of keeping the UI clean while keeping more workflows in tact

[aleksey-hoffman]

@MylesBorins hell yeah. Good to see devs listening to the feedback. Thanks guys

[Andre601]

GitHub by far listens the most to feedback.
They just recently added an option for fixed-size font in markdown fields which I suggested once. I'm happy.

[Zalaxx]

Being able to access assets attached to the release from the release list could be very convenient, just like it was before.

[MylesBorins]

This is a really great point! I'll scope this as a feature request and see if we can get this moved forward quickly 🎉

[Gakk]

I agree, assets on release list is highly wanted. But to keep the list fairly short, maybe have the assets list collapsed on all other than the latest release?

[DAOWAce]

Yeah, this change is a complete deal breaker.

I always visit the release page for a repository, not a specific release version, because I want to know if it's the latest release or if there's in-dev versions available.

This change makes it so you have to now click every individual release to see any information about them. An extra click; for something you got by default before.

Github hasn't really changed too much over the years (which is good, because it's been functional), but like most things that refresh their UI, this is a complete downgrade no matter how I can look at it.

Really hope it is not pushed to live.

[a420gmoon]

I was looking for a release body for GitHub that has reviewed what's going on.

[MylesBorins]

Assets are back on the list view, PTAL. We did notice that we regressed and no longer show the size of uploaded assets and are fixing that as we speak. We are also thinking through ways to improve navigation around the hidden content so stand by for more updates

[dnwe]

The new "auto generate release notes" is cool, though I'd love to see some support for parsing Conventional Commits structure and splitting the "What's new" section into "New Features / Improvements" and "Fixes"

[EdJoPaTo]

I assume there are a lot of smaller repos not using Pull Requests as there is mainly only one developer. (At least thats the case for a bunch of my projects)
Also there are projects not using the github gui much so Pull Requests might also not be used.
Supporting auto generated release notes just based on the actual commits in the diff will be helpful in these cases.

Not sure if config in a release.yml is a better solution here compared to already existing actions which can be configured in an already known way.
Thinking about it: A github action that can be triggered via a button in the "New Release" Gui (like on.release-auto-note) to provide an override to the built in solution might be helpful for cases like this to provide more customizability for projects.

Also stuff like auto importing CHANGELOG.md files could be realized that way.

[bcoe]

@MylesBorins I would happily collaborate on this action, I Think it would be a fairly seamless way to let folks use a flow like conventional commits.

[cawa-93]

I Agree with @EdJoPaTo: I mostly doesn't use PR's in my Project. Automatically Generated Release notes looks great, because now I must uses a separate action for that. However, support for non-PR commits is critical. Unfortunately, only because of this I will be forced to continue to use my own action to regenerate notes. 😓

Imagining what solution would suit me, I see something like this:

  categories:
    - title: Exciting New Features 🎉
      labels:
        - Semver-Minor
        - enhancement
      commits:
        - "feat:*"

...

[MylesBorins]

At this time we will not be supporting commits in the auto-generated notes. I understand that this doesn't work for everyone's workflows but we felt that we could make a better product by making strong decisions and focusing on a tight product scope.

[bcoe]

One idea we were scheming was to use a GitHub action to apply labels to a PR based on conventional-commits

FYI, I created a GitHub action for applying labels:

https://github.com/bcoe/conventional-release-labels

Feedback and help very much appreciated 🎉

[jackmcdade]

This feels like a significant step backwards for our users. The truncated notes prevent users from scanning or searching the changelog for keywords they're interested in, it makes big important releases look the same as little, patch releases, and the overall use of space is a lot harder to scan with everything being content in boxes.

I hate to leave negative feedback on a release day, but I feel very strongly about this. I really do not want to see this rolled out as the only layout option.

[Gakk]

@MylesBorins There will of course be different opinions about design, but I have to agree with @jackmcdade on this.

Whenever I am working on a project, there are a multitude of packages to upgrade (NuGet packages, actions versions, etc.), and I always open the release page of the package to scroll through what has changed. Usually I am multiple versions behind, and I need to catch up on what's new between my version 1.2 and current 1.6. Clicking "read more" could have been an option if it expanded on the page, but navigation to and from new pages for complete release notes is in my view not a good idea.

Please consider bringing back the complete release note, or make the "read more" expand on the same page, so I can expand release after release while scrolling.

An I understand that in cases like for node.js full release notes it a bit too much. But since GitHub already has compare options between releases, I consider adding the complete commit history to the release notes to be overkill. Wikipedia defines release notes to be "summary of recent changes, enhancements and bug fixes", and they are clearly not doing that.

[MylesBorins]

We are exploring a couple different options and combinations of showing the full release note in conjunction with search and will hopefully have an iteration for y'all soon!

[MylesBorins]

As a quick update. We are doing an engineering spike to determine the exact implementation but are exploring the following

• Showing the full notes for the latest release
• Showing the full notes for all releases in search results
• Highlighting search terms in search results
• An attribute to show full releases rather than abridge OR
• Making "Read More" show the full release notes rather than forward to another page

For the last two points we need to do some analysis of performance and determine what is the best path forward

[MylesBorins]

Everything except for highlighting search results just shipped, PTAL

[Gakk]

Looks good, @MylesBorins, but for me the full notes for the latest release is not expanded by default. Yhe text "read more" is still showing for latest release, even though assets are expanded by default. Anything I am missing?

[Eomm]

automatically generate release notes at the click of a button (or the call of an API).

I cannot find the new (beta) API or the new flag to get the autogenerated message here https://docs.github.com/en/rest/reference/repos#releases nor https://docs.github.com/en/repositories/releasing-projects-on-github/automatically-generated-release-notes

How could we consume it through the API?

Thks

[MylesBorins]

The API doc updates are taking a bit longer than expected... below are some docs you can use right now

---

Release Notes Docs

Using the REST API

Make a token

Follow the instructions in creating a personal access token to create a token you can use to make requests. For public repositories you only need the public_repo permission. For private repositories you'll need to enable full control of repositories for the token.

One thing to keep in mind, right now you are flagged into this feature by your account, not by a repository. So if you need to generate an account specific token to access this feature. If you want to use the GITHUB_TOKEN generated by GitHub actions we'll need to add your repository to the alpha. Open a thread in this discussion to request access for a specific repository.

Making the request

If you want to get a copy of the automatically generated release notes for a project you can use the new generate-notes API to do so!

POST /repos/{owner}/{repo}/releases/generate-notes

Parameters

Name	Type	In.	Description
owner	string	path
repo	string	path
tag_name	string	body	required - name of an existing tag or a new tag name for the release
target_commitish	string	body	optional - defaults to the repo default branch if not specified. Otherwise target commitish for the new release. If the tag name already exists, it’s ignored
previous_tag_name	string	body	optional - The name of a tag to use as the starting compare point for the release notes

Example with CURL

$ curl -i -u $USER_NAME:$GITHUB_TOKEN -d '{"tag_name": "v6.0.3"}' -H "Content-Type: application/json" -X POST "https://api.github.com/repos/MylesBorins/node-osc/releases/generate-notes"

Example with Octokit

import { Octokit } from 'octokit';

const [owner, repo] = process.argv[2].split('/');
const version = process.argv[3];
const prevTag = process.argv[4];

const octokit = new Octokit({ auth: process.env.GITHUB_TOKEN });
const { data: {name, body} } = await github.request(`POST /repos/${{ github.repository }}/releases/generate-notes`, {
  owner,
  repo,
  tag_name: version,
  previous_tag_name: prevTag
});

console.log(`\nThe title of the release is:\n\n${name}`);
console.log(`\nThe body of the release is:\n\n${body}\n`);

Example with GitHub actions

on:
  push:
    tags:
      - 'v*'

name: Create Release

jobs:
  publish:
    name: Publish to npm
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - uses: actions/setup-node@v1
        with:
          node-version: 14
      - name: Publish
        run: |
          npm config set //registry.npmjs.org/:_authToken ${NPM_TOKEN}
          npm ci
          npm publish
        env:
          NPM_TOKEN: ${{ secrets.NPM_TOKEN }}

  create-github-release:
    name: Create GitHub Release
    runs-on: ubuntu-latest
    needs: publish
    steps:
      - name: Checkout code
        uses: actions/checkout@v2
      - name: Create Release Notes
        uses: actions/github-script@v4.0.2
        with:
          github-token: ${{secrets.GITHUB_TOKEN}}
          script: |
            const version = "${{ github.ref }}";
            const { data: {name, body} } = await github.request(`POST /repos/${{ github.repository }}/releases/generate-notes`, {
              tag_name: version
            });
            await github.request(`POST /repos/${{ github.repository }}/releases`, {
              tag_name: version,
              name,
              body
            });

Automatically generate notes when using the create release API end point

If your project is using semver and you do not plan to make any changes to the automatically generated notes you can alternatively pass a boolean to the create release API.

POST /repos/{owner}/{repo}/releases

Name	Type	In.	Description
owner	string	path
repo	string	path
tag_name	string	body	required - the name of the tag
target_commitish	string	body	optional - defaults to the repo default branch if not specified. Otherwise target commitish for the new release. If the tag name already exists, it’s ignored
name	string	body	optional - The name of the release.
generate_release_notes	boolean	body	optional - Whether to automatically generate the name and body for this release. If name is specified, the specified name will be used; otherwise, a name will be automatically generated. If body is specified, the body will be pre-pended to the automatically generated notes. Default: false.

For more details on this api please check our documentation

Example Action

The below action will create a new release with automatically-generated release notes when you push a tag.

on:
  push:
    tags:
      - 'v*'

name: Create Release

jobs:
  create-github-release:
    name: Create GitHub Release
    runs-on: ubuntu-latest
    steps:
      - name: Create Release Notes
        uses: actions/github-script@v4.0.2
        with:
          github-token: ${{secrets.GITHUB_TOKEN}}
          script: |
            await github.request(`POST /repos/${{ github.repository }}/releases`, {
              tag_name: "${{ github.ref }}",
              generate_release_notes: true
            });

[MylesBorins]

First bit of API docs are now live

https://docs.github.com/en/rest/reference/repos#generate-release-notes-content-for-a-release

[aramperes]

The truncated changelogs in the new UI can be very misleading; for example if it cuts after a bullet point, it looks like that's the end of the changelog, and the 'Read more' link is not very obvious.

Consider making the 'Read more' more obvious and maybe expand the changelog in-place, instead of opening it in a new tab. Maybe make the changelog 'fade out' like a gradient so it's more obvious it's truncated (not sure if that fits with your design guidelines).

[aramperes]

Yeah that would fit with the issues. Though I admit I've overlooked these in the past as well, and not realized I missed half of the discussion in a huge thread.

[aramperes]

Quickly fiddling with devtools, this is what I had in mind (the gradient is way too intense, it's just an example)

[MylesBorins]

Thanks for sharing. We are reusing the same truncation utility that is used across github.com and have been thinking through ways of improving things. One important thing from a design-systems perspective is to ensure that things across the platform are consistent.

I've shared this thread with our designer and will see what they say.

[Gakk]

Thanks for the insight @MylesBorins. I had the same issue as @aramperes; on one of the first packages I opened after enabling the new view, I thought the 3-4 bullet points I saw was the complete release note. I expected only assets, contributors, compare functionality, etc. under the "read more", and first later noticed that the "read more" only is shown where text is truncated.

[MylesBorins]

PTAL at #5962 (reply in thread) where i talk about the improvements we are exploring

We are also now showing assets in the list view.

[jasonvarga]

Previously I'd make use of the pagination query parameter to jump near certain releases. I'd do this when trying to find out when some behavior was introduced.

I'd change the URL to ?after=v4.17.0 with the version I was interested in.

Now with the infinite loader, this isn't possible.

Admittedly, you can still do it on the tags listing, but since you can't read any of the release notes there, you have to click into each one.

[MylesBorins]

We are working on replacing the infinite loader with proper pagination but still have some work to do with underlying infrastructure first. We are hoping that folks will be able to use the search functionality for these types of workflows. As the after search was based on time of release rather than semver the results would not be consistent, but it does seem like we are losing the ability to create a search based on version range.

Will have to think on this one... thank you for raising it

[jasonvarga]

Looking at the ajax requests, it seems you're still doing the after thing.
If it was proper pagination with the "inconsistent" results, personally I'd be happy.

I think it's just being able to jump to some point in the past, rather than having to repeatedly click load more. Thanks!

Edit: oh and clicking "read more" on changelog, then returning to listing to see the pagination reset is a bit of a bummer. Regular pagination would solve that too. 🤘

[MylesBorins]

We are planning to make a bunch of improvements to pagination in the next 2 - 3 weeks, what we have right now is temporary while we improve back-end infra first

[MylesBorins]

The new pagination landed, please take a look!

[ouuan]

I don't understand how truncated notes "make viewing overall releases easier". What information can you get if long release notes are truncated? I don't think it's much more useful compared to the "Tags" page. Maybe it's a good idea to allow maintainers to add <!--more--> in the release notes to mark where "read more" should appear, and default to no truncation if no <!--more--> is provided.

In addition, I think the "xx commits to master since this release" is also a useful piece of information. I'd like to see it in the releases list.

[MylesBorins]

Please take a look at #5962 (reply in thread) for next steps we are exploring to make the hidden content a better experience

[quetzalliwrites]

I really like these improvements! I do miss also being able to quickly access assets. ✨

[MylesBorins]

We are going to bring assets back to the list view!

[quetzalliwrites]

thank you! ☺️

[MylesBorins]

Assets are back PTAL

[ArtemGoutsoul]

Doesn't work for our private repo. Getting

Not really clear what's the issue :(

[MylesBorins]

Could you take a screen capture of the process you followed to see that x? is there any other error displayed?

[ArtemGoutsoul]

The process is very basic, clicked to make a new release, then clicked on a button to "Auto-generate release notes".

Checked browser network tab, the https://github.com/xxx/xxx/releases/notes?commitish=v2021.165&tag_name=v2021.165 request returned an 502 HTML page that contains: with "This page is taking too long to load.", opened that page in a new tab:

[MylesBorins]

We found a couple of edge cases we were not expecting (including what happens if one of the PRs is from a deleted account). We have a couple fixes going live soon and I'll check back to let you know when it would be a good time to try again

[ArtemGoutsoul]

Tried again - worked for me! nice

[kbond]

Love the automatic release notes feature! I find the "Choose a tag" dropdown a bit cumbersome. I would love the option to choose the next semantic version automatically. Options for Next Major, Next Minor, Next Patch would be great!

[MylesBorins]

thanks for the suggestion @kbond

Not every project on GitHub uses SemVer so we didn't want to bake that functionality too deeply into the platform. We also don't create release commits, so for most projects published to a public registry the commit / tag would need to be made prior to the GitHub release being made.

This seems like a great place for a GitHub Action / Workflow to carve out some automation

[mnquintana]

Sort of a meta question – would you prefer Beta feedback in this thread? Or as separate threads under https://github.com/github/feedback/discussions/categories/releases-feedback?

Just want to make sure I'm posting feedback where it'll get seen / responded to by the team!

[MylesBorins]

I'm in here responding 😄

I'd say if it is a smaller item that could be discussed in a single thread it makes sense to keep it in here. If it is a much broader piece of feedback that may have multiple threads of discussion it might make sense to make a new discussion for it

[Julian]

There are a number of tools in various language ecosystems around "newsfiles" (tools with small communities but which I think are well loved) -- e.g. in the Python community we have things like towncrier.

The niche for these tools are to bridge the gap between "all commits" and "functionality with interest to end-users". Any plans to integrate with these kinds of tools or workflows?

(disclaimer -- I haven't tried to use the functionality yet :)

[MylesBorins]

We examined some of the tools that folks use for creating more structured release notes but in general they tend to require a lot of process / ritual / commitment to get it to work properly.

In designing our automated solution we focused on trying to make something that would "just work"™️ for most project with enough levers to customize via labels. Any solution that required lots of upfront work from developers just to get things to work are unfortunately non-starters for us.

[Julian]

Fair enough, sounds reasonable, certainly as a start. Thanks for the response.

[mnquintana]

It would be really helpful if the new search box was available on release detail pages (e.g. https://github.com/electron/electron/releases/tag/v16.0.0-alpha.5):

Having to do a whole page navigation back just to get access to a search box is really cumbersome.

[MylesBorins]

So you are imagining that search would still be there and take you back to a list view with the search results?

[mnquintana]

@MylesBorins Yup, exactly!

[MylesBorins]

@mnquintana we talked about it as a team and I don't think this is something that we want to move forward with right now... but it is because we are cooking up some other search improvements so please stand-by for some other cool ideas 😄

[nthoma]

Is there a way to change the base branch that the target branch is compared against to generate the release notes?

[MylesBorins]

In the UI you are able to select both a tag and the target which is how the comparison is made, the target is a committish so it doesn't have to be a branch. If the tag doesn't exist it will use the head of the branch of the target committish.

There are a few more levers you can pull if you are using the API including explicitly stating what the previous tag is to create the range for your release. Both the new tag and previous tag need to be on the same target committish

[nthoma]

I see, so there's no way to change the base branch/tag used for comparison from the UI, but there is that option in the API. Thanks for update! Any plans to add this capability to the UI view in the future?

[MylesBorins]

The target is always the base as compared to the tag... could you walk through the flow you are thinking of here because I'm not completely understanding what you are trying to do

[MylesBorins]

The target is always the base as compared to the tag... could you walk through the flow you are thinking of here because I'm not completely understanding what you are trying to do

[PromoFaux]

I'm a little confused about the auto-generate release notes feature (appreciate it's still in preview)

Playing about with it to see what it does, I am not really sure how it's deciding what to put into the release notes, take for example on pi-hole/pi-hole, we have these tags/releases:

(Ignore the top one, it's a rolling draft)

When I add a tag of, say v5.6, and click the auto-generate button, it generates notes for contributions since 5.3.1 - Should it not be taking the most recent tag before it and going from there? (or perhaps we could have an option to manually enter the "since" tag)

Now, new stuff for release is not yet in the master branch, rather development, but the same thing happens no matter which branch I choose. Would like to use this feature, as it can be quite tedious if we forget to update the rolling draft before release, so any insight would be appreciated... thanks!

[MylesBorins]

Right now we are currently using the semver algorithm to determine version ranges and it seems like perhaps we are having a couple different issues with folks using other version schemes because of that. I just finished scoping a feature request to switch to using pep440 which is far more flexible

[CallumWatkins]

Could we have an option to hide pre-release versions from the list on /releases?

[MylesBorins]

@CallumWatkins at this time this is not something we are going to be exploring. Thank you for the suggestion though.

[Andre601]

Tested this already and I must say it's already a good thing to have.
Did gave some feedback (And a request to give the responsible devs a hug from me) on the Community forums: https://github.community/t/thank-you-for-the-improved-releases-and-some-feedback-ideas/204764

[MylesBorins]

Answered on the community forum. Thanks for the feedback

[connorshea]

The tag name on the "show" view of an individual Release could be wider, right now it gets cut off even on relatively short tag names.

[MylesBorins]

Thanks for the heads up! I've documented this to review with design

[mattleibow]

This looks like it could be really good!

Is it possible to make the auto-generation select 2 commits?

I have 2 branches that release in parallel as well as I do lots of preview releases. I would love it if I could have my stable releases include all changes between stables.

[MylesBorins]

You can manually select the start and end reference if you are using the generate release notes api. We are exploring how to better show this in the UI but it is a bit more work than we have bandwidth to prioritize right now.

[mattleibow]

Thanks! I might give that a go and add a trigger to update things on a tag step. This is so cool!

[MylesBorins]

it is worth adding that when generating notes the tool will only identify PRs associated with commits on the target branch. If you are cherry-picking content to a release branch, or cutting the release from a branch that is different from where the original pull-requests were targeting you will not get notes.

[MylesBorins]

I'm going to go ahead and consider this welcome thread answered! thanks for all the great feedback. Please open new discussions for additional feedback

[Mlocik97]

In sveltejs/svelte repo, I tried new feature, and it gave me error,... with feature disabled it loaded correctly.

[MylesBorins]

@Mlocik97 can you expand on what the error is?

[Mlocik97]

Now it doesn't write error, just message:

There aren’t any releases here
Releases are powered by tagging specific points of history in a repository. They’re great for marking release points like v1.0.

But there is 365 releases, and turning off feature I can see:

https://github.com/sveltejs/svelte/releases

[MylesBorins]

@Mlocik97 this is by design. We do not automatically make GitHub releases for tags. Previously tags would show in the releases list but we have separate releases and tags as part of this initiative. There are various threads with many participants who were asking for this change in behavior

https://github.community/t/tag-without-release/857
https://stackoverflow.com/questions/28496319/github-a-tag-but-not-a-release

In this case svelte has made a bunch of tags, but there are no releases.

[MylesBorins]

I'm working on updating that default message for no releases right now to make it clearer

[przemolb]

What is this gap for ?

[MylesBorins]

We've just shipped a change to minimize this space, please take a look

[przemolb]

It looks better now - thanks.

[ArtemGoutsoul]

Hopefully an easy suggestion - can the PR titles in the changelog be sorted alphabetically?

[MylesBorins]

@ArtemGoutsoul Right now the changes are sorted based on time and that isn't something we are likely to change at this point.

[Andre601]

@ArtemGoutsoul Right now the changes are sorted based on time and that isn't something we are likely to change at this point.

How about an option in the release.yml like this?

changelog:
  order: "alphabetically"

Perhaps this could also be a list or String array to set multiple sorting options. f.e.

# Sort by date, followed by alphabet.
changelog:
  order:
  - "date"
  - "alphabetically"

This could be the best of both worlds: Keep the default behaviour for changelog order, while also giving people a way to change it.

[ArtemGoutsoul]

@MylesBorins Time based order is a bit unobvious (since most often it does not matter if some PR was merged in the morning or in the evening), alphabetical as a default would make it more readable, I think.

But I understand that it's a matter of priorities, thanks for answering!

[Seldaek]

There is a bug in the automatically generated release notes where it picks the wrong tag (the oldest tag in my case), which means it generates release notes for the entire repo history, not ideal ;)

It happens for me on the composer/composer repo, and I assume it is because tags are done in one-off commits which happen off the main branch for example this commit here for the latest 2.1.9 release composer/composer@e558c88

What happens is because we need to generate some version constants, we do this when tagging:

git checkout -b temp
[process files]
git commit -am'Release x'
git tag x
git checkout main
git branch -D temp

So you're left with a tag pointing to a commit which is in none of the branches, keeping the history a little cleaner than if we had to revert those changes every time.

I guess the auto-release-guesser thing could handle this better somehow, but I'll leave the how up to you :)

[MylesBorins]

@Seldaek this is definitely a particularly interesting workflow and edge case.

You could potentially use the generate notes API to manually set your tag_name / previous_tag_name.

https://docs.github.com/en/rest/reference/repos#generate-release-notes-content-for-a-release

edit: To be clear this might require some additional steps to get it to work, but I think the tags might be able to be replaced with a git_ref... so play around and let me know if you can get something working

[Seldaek]

Hey, to be honest I'm not going to be able to dig much deeper here, story.

I found the new feature intriguing and wanted to give it a shot but for this particular project i anyway intend to keep doing my changelog entries by hand. I figured you may be interested in fixing the issue regardless though :) I will try this again on smaller projects where i don't care as much to have a well written changelog.

[groenroos]

Apologies if this has been answered elsewhere, but is it possible to somehow exclude bot PRs from the auto-generated release notes in the UI? I consider e.g. Dependabot version bump PRs quite noisy and irrelevant, vs. "real" feature improvement PRs by humans, so it would be good to be able to exclude PRs opened by bots (or maybe even just specific bots?)

[Andre601]

You could just configure Dependabot to add a specific Label to its PR and then configure the release creator to exclude PRs with that particular label.

For example, I could configure Dependabot to add the "Changelog: Exclude" label to its future PRs like this:

version: 2
updates:
- package-ecosystem: github-actions
  directory: "/"
  schedule:
    interval: daily
  open-pull-requests-limit: 10
  labels:
  - "Changelog: Exclude"

and on the release.yml could I have it added to the exclude.labels section like this:

changelog:
  exclude:
    labels:
    - "Changelog: Exclude"

[MylesBorins]

You can also exclude authors!

https://docs.github.com/en/repositories/releasing-projects-on-github/automatically-generated-release-notes#release-template-syntax

changelog:
  exclude:
    authors:
      - dependabot

[rocklan]

I am getting a 502 when generating release notes, is it possible that someone can look at this? They don't seem to be working at all for me.

[ArtemGoutsoul]

I'm getting the same occasionally, usually works after a few retries, but definitely annoying

[MylesBorins]

Asking engineering to look into this.

[ohnnyj]

Little late to the party but I am looking forward to this being available in enterprise. Any timeline? I know it is still in beta but even a general idea would be great.

[stevespringett]

Ideally, release notes would also be available in a machine-readable format such as CycloneDX.

OWASP CycloneDX is a BOM standard (SBOM, SaaSBOM, OBOM, etc) that also includes the ability to standardize release notes, including the defects, enhancements, and security issues that were addressed and the commit and author information. Often times, release notes include security information, such as recommended configuration options to harden use of a library, or deprecation notices. Providing release notes in a machine readable format such as CycloneDX which has been adopted by the security industry would be a great addition.

See:

• https://cyclonedx.org/capabilities/release-notes/
• https://cyclonedx.org/docs/1.4/json/#components_items_releaseNotes

Related to #11252

[spaltrowitz]

this has now shipped to GHES! https://docs.github.com/enterprise-server@3.4/admin/release-notes#releases-changes