It sounds like a simple question, but it can require multiple steps to find the answer. The following description should work for most projects using GitHub releases with some minor variations. However, the specifics are for Elastic’s release strategy.
Scope the Problem #
The specific question was:
Did the Logstash pull request
#14605make the 7.17.8 release?
To make it more complex:
- The pull request was merged on the 16th of November and the 7.17.8 release happened on the 8th of December. But the
7.17.8label was only added to the pull request on the 13th of December; so after the release. Can it be trusted?
- The fix was a backport to the previous major version 7.x rather than the current one. Features and fixes are developed on the
mainbranch and are then backported on a case-by-case basis for the previous major version.
- This specific pull request needed a manual cherry-pick since it didn’t backport cleanly. That’s also the reason why the
7.17.8label wasn’t applied automatically by our backport tool.
- The fix isn’t mentioned in the release notes.
So did it make the release or not?
Follow the Source #
You can follow along with plain Git but for easier linking (and not having to clone a large repository), the following steps use the GitHub interface.
The basic assumption is that the release tag is what was released. So in this example, it’s the Logstash 7.17.8 release. The release page also shows the commit of the release —
4366546 is the shortened commit hash.
The last remaining part is the backporting strategy: Elastic projects always have a minor version branch from which the releases are cut. So in this example, it’s the 7.17 branch. You can also see that the
4366546 commit happened on that branch.
In the commit history of the branch, you can see:
4366546of the release, and before that,
69ce6ebof the bugfix in question.
So it has indeed been part of the release.
Wrapping Up #
Usually, the quickest way to answer “did a pull request make a specific release” is through the release notes. Or if that is missing, since it’s a manual process for now, through the release label on the pull request. But if that’s also missing or cannot be fully trusted, you must follow along with the source.