You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
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++): ...
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?
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.)
Activity
kou commentedon Jan 10, 2025
@wgtmac Do you have any preference for this?
lidavidm commentedon Jan 10, 2025
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.
wgtmac commentedon Jan 10, 2025
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
lidavidm commentedon Jan 10, 2025
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'schore(ci): ...orfeat(c++): ...kou commentedon Jan 10, 2025
OK. Let's try it for the next release.
We can revisit this after the next release.
lidavidm commentedon Jan 13, 2025
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, andenhancementcategories, and an action that asks for at least one of the three to be set?lidavidm commentedon Jan 30, 2025
@kou @jbonofre do we want to get this done before the release? Or will we just use the default changelog for now?
jbonofre commentedon Jan 30, 2025
Both is ok for me. But clearly it has to be fixed.
lidavidm commentedon Jan 30, 2025
If those three tags are OK, I can set them up real quick and go back and tag PRs (maybe also a
choretag for things like CI/release processes)jbonofre commentedon Jan 30, 2025
FYI, on Apache Camel, we just use GitHub Milestone link. Maybe we can start from there ?
lidavidm commentedon Jan 30, 2025
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.
jbonofre commentedon Jan 30, 2025
Yes, and also maybe we can also create some "manual" GitHub Issues on the target milestone (if it helps the end users).
lidavidm commentedon Jan 30, 2025
I believe the changelog will just use commit messages since the base tag
kou commentedon Jan 30, 2025
Ah, we may need to write a release note for 18.2.0 manually. Because there is no base tag now...
9 remaining items
jbonofre commentedon Feb 6, 2025
Maybe we can create the diff between 18.1.0 and the current 18.2.0 rc ?
That would create a useful change log.
kou commentedon Feb 7, 2025
Oh! I didn't notice the feature!
gh release createhas--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.)kou commentedon Feb 7, 2025
I've removed https://github.com/apache/arrow-java/releases/tag/v18.2.0-rc4 and re-generate changelogs for https://github.com/apache/arrow-java/releases/tag/v18.2.0-rc5 for now.
apacheGH-499: Require PR labels for changelog
apacheGH-499: Require PR labels for changelog
apacheGH-499: Require PR labels for changelog
apacheGH-499: Require PR labels for changelog
apacheGH-499: Require PR labels for changelog
apacheGH-499: Require PR labels for changelog
apacheGH-499: Require PR labels for changelog
apacheGH-499: Require PR labels for changelog
lidavidm commentedon Feb 7, 2025
Draft at #594
apacheGH-499: Require PR labels for changelog (apache#594)