proposal: release-please: make it possible to write library versions to librarian.yaml

[julieqiu]

Several language repositories use release-please for releases and are incrementally migrating to librarian, which tracks library versions in librarian.yaml.

The version in librarian.yaml matters because librarian generate embeds it into the generated source. Today, release-please has no awareness of this file, so versions can drift if a repo adopts librarian for generation but not for version bumping.

We should add a release-please updater that writes the released version to the corresponding entry in librarian.yaml. As a precedent, release-please updates internal/version.go:

• https://github.com/googleapis/release-please/blob/main/src/strategies/go-yoshi.ts#L71-L76
• https://github.com/googleapis/release-please/blob/main/src/updaters/go/version-go.ts#L18-L24

A similar approach can locate the matching library entry in librarian.yaml and update its version field.

This lets us split the migration process so that repos can adopt librarian for generation independently of release.

[julieqiu]

I thought about this some more, and I wonder if a simpler stopgap would be to have librarian generate read from release-please-config.json. When we update librarian.yaml, we always run generate in the same commit to keep the libraries in sync.

Otherwise, we would need to run librarian generate --all when running release-please to keep things in sync.

/cc @jskeet

[jskeet]

I think it's .release-please-manifest.json that contains the actual version numbers, but otherwise, yes. (We may need to read the config as well as the manifest, I'm not sure.)

One downside of this approach is that between a release and the next generation, the repo is inconsistent. Anyone looking at librarian.yaml and expecting it to be the source of truth could end up looking at the wrong version number. Likewise we wouldn't be able to put in a presubmit check that the version numbers are in sync (which we could do if we modified release-please instead).

I haven't tried to weigh up how that downside balances against the cost of changing release-please.

Otherwise, we would need to run librarian generate --all when running release-please to keep things in sync.

I'm not sure I follow what this is "otherwise" to. (If it's release-please that modifies librarian.yaml, we wouldn't need to run librarian generate --all at all. I think I'm confused.)

[julieqiu]

Anyone looking at librarian.yaml and expecting it to be the source of truth could end up looking at the wrong version number.

I was actually thinking with this approach we would just not put the version number in librarian.yaml at all. So librarian bump and librarian generate would read directly from .release-please-manifest.json.

I'm not sure I follow what this is "otherwise" to. (If it's release-please that modifies librarian.yaml, we wouldn't need to run librarian generate --all at all. I think I'm confused.)

The current step in the release process is to:

• Run librarian bump
• Run librarian generate --all

If we update librarian.yaml, but don't run librarian generate --all, then the code will out of sync. Example PR:
googleapis/google-cloud-rust@e3c0870

[jskeet]

I was actually thinking with this approach we would just not put the version number in librarian.yaml at all. So librarian bump and librarian generate would read directly from .release-please-manifest.json.

Ah, so the language-specific generate functions would still get in-memory structs with the right version, but they wouldn't be sourced from librarian.yaml, right?

The current step in the release process is to:

• Run librarian bump
• Run librarian generate --all

That's not what I'd have expected. I'd expect "librarian bump" to make all the required changes to all files. (So in Go for example, I'd expect it to update internal/version.go and snippet metadata files.)

If we update librarian.yaml, but don't run librarian generate --all, then the code will out of sync. Example PR:
googleapis/google-cloud-rust@e3c0870

But I'd expect release-please to make all the relevant code changes - so that running "librarian generate --all" afterwards would be a no-op. But this may be akin to the above misalignment on what "librarian bump" should do.

[JoeWang1127]

I was actually thinking with this approach we would just not put the version number in librarian.yaml at all. So librarian bump and librarian generate would read directly from .release-please-manifest.json.

I think we should modify release-please to update version in librarian.yaml. In this way, when we need to migrate release off release-please, we just need to disable release-please, no need to update librarian. This step needs to be done before the generate migration.

After generate is migrated to librarian, we can create a check in the language repo to verify the library configs are consistent among release-please and librarian.

I've created tool/cmd/configcheck to check librarian and legacylibrarian configs and it can be expanded to release-please config.

The check is implemented via googleapis/google-cloud-go#14327.

[julieqiu]

I've created tool/cmd/configcheck to check librarian and legacylibrarian configs and it can be expanded to release-please config.

The check is implemented via googleapis/google-cloud-go#14327.

Nice! in this check, how does pubsub/v2/internal/version.go and pubsub/internal/version.go get updated? It doesn't look like https://github.com/googleapis/librarian/blob/main/tool/cmd/configcheck/main.go runs librarian generate.

[JoeWang1127]

how does pubsub/v2/internal/version.go and pubsub/internal/version.go get updated?

I updated the version manually and rerun librarian generate -all.

These two version are updated by legacylibrarian release stage (googleapis/google-cloud-go#14312 and googleapis/google-cloud-go#14314).

I added the function to update library versions in librarian.yaml in v0.9.1 but the legacylibrarian version used in this release is old (v0.8.3).

[jskeet]

I'd expect "librarian bump" to make all the required changes to all files.

I've been thinking about this overnight, and it's something we should make completely clear when designing the new release flow.

I like the idea of any given file only being changed by either bump or generate, but not both - on the other hand, I'm also not hugely keen on regenerating absolutely everything just to touch the few files that contain version numbers. Will think more.

[JoeWang1127]

See go/sdk-librarian-uvm