Issue #21656 has been updated by nevans (Nicholas Evans). Earlopain (Earlopain _) wrote in #note-4:
`net-imap` actually uses it already: https://github.com/ruby/net-imap/blob/079167e99b47957d53c71c927ebbca537aae39.... The name does need to be `dependabot[bot]` I think. https://github.com/ruby/net-imap/releases/tag/v0.5.11 does still mention dependabot for them
`net-imap`'s release.yml _is_ working as I'd intended. 🙂 Note that the exclusion is for the "Other changes" section and that ensures the dependabot PRs go into the "Miscellaneous" section. Also, `net-imap`'s release.yml only creates a draft, which I manually proofread/edit before publishing. I've classified PRs in `net-imap`'s release notes as: * changes library code: * **Breaking Changes** FWIW, I consider changes to minimum versions of the gem's own dependencies as "breaking". E.g: bumping the minimum ruby version. * **Deprecated** _(probably adds new warnings)_ * **Added** * **Fixed** * **Other Changes** _(e.g: refactoring, performance improvements, improved error messages, or any other minor code change that isn't classified as one of the above)_ * changes library docs, but not code: * **Documentation** * does not change library code or docs: * **Miscellaneous** _(e.g: PRs that contain nothing but new/updated tests, new/updated benchmarks, CI workflow changes, release/build scripts)_ Since Dependabot only updates the CI and release workflows, but nothing in lib (nor the gemspec deps), it's classified as "Miscellaneous". If you can think of a better title for this than "miscellaneous", I'll switch to use that instead. :) Other gems use a simpler categorization (e.g: rdoc and irb both use "Enhancements", "Bug Fixes", "Documentation", and "Other Changes"), and that's fine too. But, relevant to the discussion in this ticket, I find release notes _much_ more useful when they make a distinction between "other changes" that (directly) affect code/docs and "other changes" that don't. _With that distinction made,_ I slightly prefer keeping dependabot updates in the release notes, because they _do_ (indirectly) affect the released gem, which is built by files that are updated by dependabot, only after passing tests that are managed by files that are updated by dependabot. And I'd rather err on the side of including everything than leaving something out. But, _without_ that distinction, I think it's good to exclude dependabot updates from the release notes. ---------------------------------------- Misc #21656: Exclude dependabot PRs from automated gem release notes https://bugs.ruby-lang.org/issues/21656#change-114982 * Author: Earlopain (Earlopain _) * Status: Assigned * Assignee: hsbt (Hiroshi SHIBATA) ---------------------------------------- Ruby has many gems, and many of them have release notes generated with the github command line instead of being written by a human. Usually that is fine, I don't have much of a problem with that approach. But what is less ideal is that github actions are pinned by commit hash/minor version which causes many dependabot PRs. This results in release notes like this: https://github.com/ruby/timeout/releases/tag/v0.4.4 ``` Bump rubygems/release-gem from 1.1.0 to 1.1.1 by @dependabot[bot] in #56 Bump step-security/harden-runner from 2.10.2 to 2.10.3 by @dependabot[bot] in #57 Bump step-security/harden-runner from 2.10.3 to 2.10.4 by @dependabot[bot] in #59 Bump step-security/harden-runner from 2.10.4 to 2.11.0 by @dependabot[bot] in #60 Bump step-security/harden-runner from 2.11.0 to 2.11.1 by @dependabot[bot] in #61 Bump step-security/harden-runner from 2.11.1 to 2.12.0 by @dependabot[bot] in #62 Bump step-security/harden-runner from 2.12.0 to 2.12.1 by @dependabot[bot] in #63 Gracefully handle a call to ensure_timeout_thread_created in a signal handler by @eregon in #64 Bump step-security/harden-runner from 2.12.1 to 2.12.2 by @dependabot[bot] in #65 Bump step-security/harden-runner from 2.12.2 to 2.13.0 by @dependabot[bot] in #66 Bump actions/checkout from 4 to 5 by @dependabot[bot] in #67 Bump step-security/harden-runner from 2.13.0 to 2.13.1 by @dependabot[bot] in #68 Add a workflow to sync commits to ruby/ruby by @k0kubun in #69 ``` You might have missed it but hidden between all the automated non-user facing PRs is actually something that users might want to read about: `Gracefully handle a call to ensure_timeout_thread_created in a signal handler by @eregon in #64`. I would like these release notes to omit bot PRs since they don't have any impact on gem consumers and only make it hard to actually find what changed. Doing a quick search, 56 gems create release notes in this way: https://github.com/search?q=org%3Aruby+lang%3Ayml+--generate-notes&type=code. Really, I would want these written by a human since even without bot PRs there are still many that are just maintenance to fix CI or similar that don't concern the end user but I can understand that probably no one actually wants to write these by hand, which is why I propose to just exclude bot PRs. That should already have a pretty big impact. -- https://bugs.ruby-lang.org/