Use devVersion OS config when creating new versions

[bschwedler]

Problem

bakery create version copies the OS list from the latest version. If the devVersion has a different OS config (added OS, dropped OS, changed platforms), the new version won't reflect it.

Dependencies already come from image-level dependencyConstraints. OS config should too — via the devVersion.

Today

bakery create version connect 2026.03.0 --subpath 2026.03

• OS list: copied from latest version
• Dependencies: resolved from image-level constraints

Proposal

• OS list: copied from devVersion
• Fallback: copy from latest if no devVersions exist
• Multiple devVersions: use the first (or require consistent OS lists)

Caveat: platforms may differ

devVersion OS entries often omit platforms (defaults to [amd64]). Release versions may have explicit [amd64, arm64]. Switching to devVersion as the OS source could silently narrow platform support.

Approach	Trade-off
Use devVersion as-is	Simple; may drop platforms
Merge platforms from latest for shared OSes	Preserves platforms; more complex
Image-level platforms field	Eliminates drift; schema change

Suggested path: use devVersion as-is, and have the release workflow surface OS differences in the PR body so reviewers can catch platform changes.

Related

• Create workflow for automatically updating product versions #349 — release workflow (parent issue)
• PR Add bakery CLI commands for release automation #393 — bakery CLI changes for release automation

[bschwedler]

Concrete case of this in posit-dev/images-package-manager#103: RHEL 10 was added to the preview/daily devVersions blocks alongside the 2026.05.0 release entry, and Development workflow broke immediately:

• https://github.com/posit-dev/images-package-manager/actions/runs/29534302493/job/87741896666

Two additions to the analysis above:

devVersions has a live blast radius. It's not just a seed for bakery create version — it drives the Development workflow's matrix for the current latest/rolling version right now. Adding an OS there broke CI before any new version was ever cut.

devVersion can be early, not just incomplete. The caveat above is about missing platforms. This was the opposite: an OS declared before it was actually buildable. A blind copy (as proposed) would propagate that same mistake into every future release version with no review step.

Separately: chasing this down turned up a real bug in architecture_generalized_download_url (posit_bakery/config/image/posit_product/main.py) — arch_identifier is hardcoded to amd64/x86_64 with no arm64/aarch64 handling, so it only works for Debian-like OSes by coincidence. Filing that on its own rather than here.

Might be worth gating new devVersion OS entries on the artifact-availability check that already exists for version_templatable channels (HEAD probe / ArtifactNotAvailableError, same file), instead of relying on a reviewer catching it in a PR body.