posit-dev / posit-dev/images-shared
Use devVersion OS config when creating new versions
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 2
- Forks
- 0
- Avg merge
- 4d 13h
- Merged PRs (30d)
- 22
Description
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
latestversion - Dependencies: resolved from image-level constraints
Proposal
- OS list: copied from devVersion
- Fallback: copy from
latestif 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
- #349 — release workflow (parent issue)
- PR #393 — bakery CLI changes for release automation
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start at the bakery create version command and trace how it currently selects the OS list from latest, then inspect how devVersions and image-level dependency constraints are represented. Done means new versions use the selected devVersion OS config, fall back to latest when none exist, and account for the stated multiple-devVersion and platform differences.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- cli, release
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 48/100