legacylibrarian: Consider restoring chore as a no-op commit when determining release eligibility

[noahdietz]

Background

In "release only" mode, legacylibrarian release state currently deems a library as "eligible for release" if there is any commit since the last tag that touches any of the libraries artifacts in any capacity. This is to say that conventional commits are not consulted for determining if the commit contains a "meaningful" change.

librarian/internal/legacylibrarian/legacylibrarian/commit_version_analyzer.go

Lines 172 to 182 in 9cb2da5

	func NextVersion(commits []*legacygitrepo.ConventionalCommit, currentVersion string, releaseOnlyMode bool) (string, error) {
	highestChange := getHighestChange(commits)
	if releaseOnlyMode && len(commits) > 0 {
	// Librarian generate does not have commit message, in order for legacylibrarian
	// stage recognize a commit made by librarian generate, update the highestChange
	// to minor.
	// Do not change the behavior if no commit is associated with this library.
	highestChange = semver.Minor
	}
	return semver.DeriveNext(highestChange, currentVersion, semver.DeriveNextOptions{})
	}

There is still the release_exclude_paths (e.g. those added in googleapis/google-cloud-python#16908) to configure excluding files from the release eligibility evaluation.

Problem

Recent Go and Python releases (fulfilled or otherwise) have resulted in a vast majority of libraries (if not all of them) being bumped and released (Go example, Python example).

We'd like to be able to make make benign changes to libraries without triggering a release. For example, changing the License header year en masse should not be bulk release trigger. We'd like to be able to use the conventional commit type chore to signify a no-op change that shouldn't trigger a release.

Potential Solution(s)

Respect no-op, use minor

We could change the above code to respect when the highestChange is semver.None (indicating a no-op) and not bump the library, rather than always forcing semver.Minor. Update playbooks to classify standard (re)generation PRs as feat so that bulk regeneration following API sources updates trigger releases in libraries it touched.

Change nothing

Keep doing what we are doing with the understanding that any change, even those we know to be benign/non-functional, will trigger a release in the client. We will often have large bulk releases, especially if we regularly update dependencies en masse.

Restore conventional commit semver

Remove the release-only mode gate, effectively restoring the conventional commit semver change decision logic. This isn't really a goal at the moment, we really just want to make more pointed release eligibility decisions.

Preferred solution

Respect no-op, use minor

[noahdietz]

Here is the proposed code change to implement the Respect no-op, use minor solution: noahdietz@050b3a5.

It simply opts out a "highest change" of semver.None from being forced into a semver.Minor bump, thus resulting in no suggested bump, thus not triggering a release for the library.