Which version given PR was released in?

[findepi]

When looking at specific changes in DataFusion, sometimes one ends up wondering which version given PR was released in.

I cannot find a good way to see this in Github UI.

Proposed solution

Associated merged PRs with next release milestone, automatically.

[shanesveller]

FWIW this is a fairly common GitHub UI concern IME, and there are a few ways to answer this yourself even if the project doesn't make any procedural changes.

When viewing a given PR, if you identify its merged commit and visit the URL for that individual commit, it will describe which Git tag(s), if any, contain the commit in question. Since the Datafusion project reliably tags their releases, this should indicate which release(s) have included that change, assuming the code in question didn't evolve further since that PR.

Here are some "worked examples" of a few arbitrarily chosen PRs:

Via GitHub UI

12986

#12986

@alamb alamb merged commit 0011f45 into apache:branch-42 Oct 17, 2024

Screenshot of tag display for commit 0011f45

This change (predictably) was first available in 42.1.0 RC1.

10000

#10000

@alamb alamb merged commit 78f8ef1 into apache:main Apr 8, 2024

Screenshot of tag display for commit 78f8ef1

This change was first available in 38.0.0 RC1.

8000

#8000

@alamb alamb merged commit 747cb50 into apache:main Oct 31, 2023

Screenshot of tag display for commit 747cb50

This change was first available in 33.0.0 RC1.

CLI

This information can also be determined using vanilla Git CLI commands if you have a local clone of Datafusion.

$ git tag --contains 0011f45
42.1.0-rc1
$ git tag --contains 78f8ef1 --sort=version:refname
38.0.0      38.0.0-rc1  39.0.0      39.0.0-rc1  40.0.0      40.0.0-rc1  41.0.0      41.0.0-rc1  42.0.0      42.0.0-rc1  42.1.0-rc1
$ git tag --contains 747cb50 --sort=version:refname
33.0.0      34.0.0      34.0.0-rc3  36.0.0      36.0.1-rc1  37.0.0-rc2  37.1.0-rc2  39.0.0      40.0.0-rc1  42.0.0
33.0.0-rc1  34.0.0-rc1  35.0.0      36.0.0-rc1  37.0.0      37.1.0      38.0.0      39.0.0-rc1  41.0.0      42.0.0-rc1
33.0.0-rc2  34.0.0-rc2  35.0.0-rc1  36.0.1      37.0.0-rc1  37.1.0-rc1  38.0.0-rc1  40.0.0      41.0.0-rc1  42.1.0-rc1

I assume there is some way to query the GitHub API, perhaps via their gh CLI, to obtain the mapping from merged PR number to merged commit, but I haven't a good reason to work that out so far.

[alamb]

Associated merged PRs with next release milestone, automatically.

This sounds like a good idea to me @findepi -- do you know how to configure / set this up?

[findepi]

@shanesveller thanks for explaining this. I know this, but this will surely be helpful for others.
My point is -- this is quite a bit of work, whereas the information could be readily available and easily accessible .

This sounds like a good idea to me @findepi -- do you know how to configure / set this up?

@alamb i would be tempted to copy a solution form some other OSS project that has it.
For example Trino does this here: https://github.com/trinodb/trino/blob/e2a01389221326a9468fddd6b318206fe2acf0ea/.github/workflows/milestone.yml
The necessary ingredient is being able to derive the version string of the next release from the source code.
I don't know how we should do this, but we might do this by the following: change release process so that the version is incremented right after the release, not before.
Some other way is to always assign PRs to next-release milestone and rename that milestone during the release process.

@alamb @andygrove thoughts?

[alamb]

In my opinion, adding version information to issues / PRs is a value to users so if we can figure out how to do it, we should

However, given I think maintainer bandwidth is the most limited resource we have, any solution we come up with should require little / no additional effort during code review.

@alamb i would be tempted to copy a solution form some other OSS project that has it.
For example Trino does this here: https://github.com/trinodb/trino/blob/e2a01389221326a9468fddd6b318206fe2acf0ea/.github/workflows/milestone.yml

I think it is a great idea.

One idea I had was what if we added github labels retroactively after the release? For example, we could write a script that ran over all commits and added a label for the first commit it appears in. There is some version of such a script (used for components in arrow-rs: https://github.com/apache/arrow-rs/blob/master/dev/release/label_issues.py.

[findepi]

The proposed solution would work, except that recently merged PRs would lack information we want to provide.

Let's maybe go with next-release milestone, which is renamed during release. WDYT?

[alamb]

The proposed solution would work, except that recently merged PRs would lack information we want to provide.

Let's maybe go with next-release milestone, which is renamed during release. WDYT?

Seems like a reasonable approach to me -- if you can document it we can give it a try for this the 43 release maybe