chore: add script to generate release notes based on commit history

[meltsufin]

The script takes the following inputs:

• module name: as specified in versions.txt
• module directory: path in the monorepo
• version: version as found in versions.txt

It scans backwards through the git history of versions.txt to find the commit where the version was changed to the provided version. It then finds the commit where the previous non-snapshot version was set. It uses this commit range to generate the commit history affecting that directory.

This also adds missing release notes for spanner and bigquery.

Fixes #12864.

[gemini-code-assist]

Code Review

This pull request introduces a script to automate the generation of release notes based on commit history for specific modules. The review identified several improvements: the module name should be escaped in regex patterns to prevent issues with special characters, progress messages should be directed to stderr to avoid polluting output, and the logic for handling initial releases needs adjustment to ensure the full commit history is included.

[meltsufin]

/gemini review

[gemini-code-assist]

Code Review

This pull request introduces a Python script, generate_module_notes.py, designed to automate the generation of release notes for specific modules within a monorepo by analyzing Git history and commit messages. It includes a fallback mechanism to scan pom.xml files when versions.txt history is insufficient. Feedback identifies a potential issue with the regex used for version extraction in Maven files, which might incorrectly capture parent POM versions. Additionally, a logic bug was noted in the commit range calculation when using pom.xml history, specifically regarding how the target commit is identified and handled when it is the most recent change.

[gemini-code-assist]

The regex used to extract the version from pom.xml is too broad. re.search(r"<version>([^<]+)</version>", content) will match the first occurrence of a <version> tag, which in many Maven files belongs to the <parent> block rather than the project itself. This could lead to incorrect version detection if the module has a parent POM with a different version. Consider using a more specific regex that targets the project's version, for example by looking for the version tag that follows the project's <artifactId>.

[gemini-code-assist]

The logic for determining the commit range from pom.xml history has a bug when multiple commits have the same target_version or when the target_version is the current tip of the branch.

1. Falsy check: if ver == target_version and not target_end_commit: treats None as falsy. If the target version is found in the first commit of the log (pom_commits[0]), target_end_commit is set to None. In the next iteration, not target_end_commit will be true again, and it will incorrectly overwrite target_end_commit with the previous commit hash.
2. Off-by-one/Missing commits: If target_end_commit is incorrectly set to a commit hash instead of None, the range target_end_commit~1 might exclude the most recent commits.
3. Invalid reference: If target_end_commit remains None (e.g., if the version was only found in the first commit), line 159 will attempt to create an invalid git reference None~1.

Consider using a sentinel value or a boolean flag to correctly track when the target version range end is found.

            target_end_commit = "NOT_FOUND"
            prev_start_commit = None
            found_target = False

            for commit in pom_commits:
                show_cmd = ["git", "show", f"{commit}:{pom_path}"]
                try:
                    content = run_cmd(show_cmd)
                except SystemExit:
                    continue

                match = re.search(r"<version>([^<]+)</version>", content)
                if match:
                    ver = match.group(1)

                    if ver == target_version:
                        found_target = True
                        if target_end_commit == "NOT_FOUND":
                            # Moving backwards, this is the first commit with target version!
                            # The previous commit in loop was the one that changed it AWAY from target version!
                            target_end_commit = prev_commit_in_loop

                    elif (
                        found_target
                        and ver != target_version
                        and "-SNAPSHOT" not in ver
                    ):
                        # This is the commit where the previous stable version was set!
                        prev_start_commit = commit
                        print(
                            f"Found previous stable version {ver} at {commit}",
                            file=sys.stderr,
                        )
                        break

                prev_commit_in_loop = commit

            if prev_start_commit and found_target:
                prev_commit = prev_start_commit
                if target_end_commit != "NOT_FOUND" and target_end_commit is not None:
                    # Use W~1 to be exclusive of W (the commit that changed it away)
                    target_commit = f"{target_end_commit}~1"
                else:
                    # Target version is the current version, use the latest commit in the log
                    target_commit = pom_commits[0]
                print(f"Using range derived from pom.xml: {prev_commit}..{target_commit}", file=sys.stderr)

[meltsufin]

@logachev Does this look right for Bigquery for filling the missed versions?

[meltsufin]

@olavloite Does this look like the right release notes for these recent releases?