GH-15000: [Dev][Release] Update changelog.md with latest release changelog

[raulcd]

The release changelog hadn't been updated since the release 6.0.1.

This PR regenerates the changelog adding information up until 10.0.1 using:

archery release changelog regenerate

Changes have been made to archery to generate it on this PR: #33615 in order to be able to retrieve the issues from GitHub instead of JIRA.

• Closes: [Release] Changelog.md on master branch has not been updated since 6.0.1 #15000

[github-actions]

• Closes: [Release] Changelog.md on master branch has not been updated since 6.0.1 #15000

[github-actions]

⚠️ GitHub issue #15000 has been automatically assigned in GitHub to PR creator.

[raulcd]

I've regenerated the changelog fully as a way of testing my changes to archery release scripts using GitHub instead of JIRA and in order to add the missing releases from the Changelog. There are some minor changes to some old changelogs mainly due to issues being assigned to a single milestone on GitHub but to more than one fix version on JIRA. We used to add tickets to both the minor release and the next major release but on GitHub we have only added it to the minor milestone. Mainly because an issue can only have a single milestone.

As a practical example: https://issues.apache.org/jira/browse/ARROW-3353
This issue appeared on both the 0.11.1 and 0.12.0 changelogs. It now appears only on the 0.11.1 changelog as the GitHub assigned issue is set to the 0.11.1 milestone: #19685

I don't think that is a problem as we are already delivering all tickets that pertain to a minor release on the next major release, like:

• 11.0.0 will include all tickets that were part of 10.0.1 even if they are not included in the 11.0.0 changelog.

@kou any thoughts?

[kou]

How about cherry-picking old changelogs from release branch instead of re-generating changelogs?

For example, git cherry-pick f786b8d5e034217dda420bda10d9749c0b66e971 for 10.0.1: f786b8d
(Unfortunately, the command reports a merge conflict... But resolving the conflict isn't hard.)

How about adding a post release task that cherry-picks a changelog to master like ADBC?
FYI: apache/arrow-adbc#335 ADBC replaces the changelog file but I think that we can use cherry-pick approach.

[raulcd]

That makes sense to me, we can add a post release task for it and I can cherry pick all the old changelog commits individually to master.

There is still a slight change on the generation of new changelogs due to the GitHub issues being on a single milestone, instead of more than one fix version but I think that's ok for newly generated changelogs.

[kou]

There is still a slight change on the generation of new changelogs due to the GitHub issues being on a single milestone, instead of more than one fix version but I think that's ok for newly generated changelogs.

I think so too.

[raulcd]

Closing this as we will take a different approach as discussed on the comments.