Skip to content

[Release] How to create release note? #499

Closed

Description

@kou

Describe the enhancement requested

From #496 (comment) :

I suppose we should consider something like conventional commits for this repo too? Or else manually curate a CHANGELOG.md?

Activity

  1. kou commented on Jan 10, 2025

    @kou
    MemberAuthor

    @wgtmac Do you have any preference for this?

  2. lidavidm commented on Jan 10, 2025

    @lidavidm
    Member

    I have a slight preference for conventional commits given we use it on go and ADBC. But we could keep the existing format and just write a script to scrape commits and make a basic changelog too.

  3. wgtmac commented on Jan 10, 2025

    @wgtmac
    Member

    Is there any benefit from conventional commits to create release note? @lidavidm

    I don't have a preference yet. I used JIRA to create release note for Apache ORC and Apache Parquet (before switching to Github issue) which is convenient.

    I am not sure if we can leverage this to customize it: https://docs.github.com/en/repositories/releasing-projects-on-github/automatically-generated-release-notes

  4. lidavidm commented on Jan 10, 2025

    @lidavidm
    Member

    The GitHub generation looks interesting. Why don't we try it out?

    Conventional commits is basically just a common standard. It's not too different from the existing convention, just instead of [CI] or [C++] it's chore(ci): ... or feat(c++): ...

  5. kou commented on Jan 10, 2025

    @kou
    MemberAuthor

    OK. Let's try it for the next release.
    We can revisit this after the next release.

  6. lidavidm commented on Jan 13, 2025

    @lidavidm
    Member

    I think we'll need to set up some labels, and then probably some automation to ensure labels are applied to PRs. Maybe to start with just breaking-change, bug-fix, and enhancement categories, and an action that asks for at least one of the three to be set?

  7. lidavidm commented on Jan 30, 2025

    @lidavidm
    Member

    @kou @jbonofre do we want to get this done before the release? Or will we just use the default changelog for now?

  8. jbonofre commented on Jan 30, 2025

    @jbonofre
    Member

    @kou @jbonofre do we want to get this done before the release? Or will we just use the default changelog for now?

    Both is ok for me. But clearly it has to be fixed.

  9. lidavidm commented on Jan 30, 2025

    @lidavidm
    Member

    If those three tags are OK, I can set them up real quick and go back and tag PRs (maybe also a chore tag for things like CI/release processes)

  10. jbonofre commented on Jan 30, 2025

    @jbonofre
    Member

    FYI, on Apache Camel, we just use GitHub Milestone link. Maybe we can start from there ?

  11. lidavidm commented on Jan 30, 2025

    @lidavidm
    Member

    Right, that's what I meant by "default changelog", GitHub just puts all the commits into the milestone. If that's ok then feel free to proceed.

    I'd like to do a bit of categorization eventually though since a changelog of just "bump dependency" is a bit cluttered and not very useful.

  12. jbonofre commented on Jan 30, 2025

    @jbonofre
    Member

    Yes, and also maybe we can also create some "manual" GitHub Issues on the target milestone (if it helps the end users).

  13. lidavidm commented on Jan 30, 2025

    @lidavidm
    Member

    I believe the changelog will just use commit messages since the base tag

  14. kou commented on Jan 30, 2025

    @kou
    MemberAuthor

    Ah, we may need to write a release note for 18.2.0 manually. Because there is no base tag now...

  15. 9 remaining items

  16. jbonofre commented on Feb 6, 2025

    @jbonofre
    Member

    Maybe we can create the diff between 18.1.0 and the current 18.2.0 rc ?
    That would create a useful change log.

  17. kou commented on Feb 7, 2025

    @kou
    MemberAuthor

    Oh! I didn't notice the feature!

    gh release create has --notes-start-tag string Tag to use as the starting point for generating release notes. So we can use it since the next release. (We can't use it for 18.2.0 because we don't have the 18.1.0 tag in this repository.)

  18. kou commented on Feb 7, 2025

    @kou
    MemberAuthor
  19. added 8 commits that reference this issue on Feb 7, 2025
  20. lidavidm commented on Feb 7, 2025

    @lidavidm
    Member

    Draft at #594

  21. added a commit that references this issue on Feb 18, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions