3 ms·

In summary: Henceforth releasenotes will consist of mostly automated dependency bumps and the same commit messages that you can also see in the commit history.

• arve0 5y ago
  …which is nice, when the master is not tagged and you’re trying to find out “does this release include the bug fix in pr #123” (without cloning and/or jumping between tags/branches).
  • krono 5y ago
    There's already a "compare" selector on the current/old releases page that lets you do just that with two clicks.
    • arve0 5y ago
      Thank you, that is useful, but basically same as "jumping" between branches. @pronik's reply was spot on, viewing the merge commit, which shows which branches and tags the commit is included in. Example: https://github.com/openshift/okd/commit/e278fba2d8a5aea6b7bd2636dce548f8d3463e11 https://github.com/openshift/okd/commit/e278fba2d8a5aea6b7bd...
  • pronik 5y ago
    Which is extremely easy: you click on the actual patch that has been merged and look under the commit message where all the tags containing this particular commit are shown.
    • arve0 5y ago
      Thank you. Tried on the commit in PR, did not show up, but the merge commit did. I guess it's dependent on merge strategy, where squash merge will not include the initial commit hash. Or maybe "pr commit view" excludes the same info.
• momothereal 5y ago
  - You can configure the auto-generated changelog to exclude users (e.g. dependabot) and labels[1] - The automated changelog is based on PR titles, which allows you to edit them without rewriting history, and labelling them for filtering/grouping. [1] https://docs.github.com/en/repositories/releasing-projects-on-github/automatically-generated-release-notes#example-configuration https://docs.github.com/en/repositories/releasing-projects-o...
  • krono 5y ago
    Those details should definitely have been a part of the blog post!