Skip to content

Post-2026.1.0.52 sweep, Tier 1: Python 3.13, save-as-blueprint global inputs, blueprint category validation - #24

Merged
nahumtimerman merged 1 commit into
mainfrom
docs/2026.1-patch-sweep-tier1
Sep 10, 2026
Merged

Post-2026.1.0.52 sweep, Tier 1: Python 3.13, save-as-blueprint global inputs, blueprint category validation#24
nahumtimerman merged 1 commit into
mainfrom
docs/2026.1-patch-sweep-tier1

Conversation

@nahumtimerman

Copy link
Copy Markdown
Collaborator

First batch of the catch-up for everything that landed on 2026.1 after the 2026.1.0.52 pass (#18) and was not covered by #19#22. This tier is the behavior-changing set; the new APIs and the remaining fixes follow in Tier 2 and Tier 3.

Bundled Python 3 → 3.13.15 (64-bit)

Trunk CS 189997 (+ 189988 canary suite, 189999 binaries), backported to 2026.1 in CS 190003. From CPython 3.9.9 (32-bit).

The important nuance, verified against the source rather than the changeset comment: this is the Windows bundled slot only. Tools/DockerExecutionServer/Dockerfile still builds Python 3.9.9, as do the Linux virtual appliance and the from-script ES. So every page states the platform split instead of a blanket "CloudShell now uses Python 3.13", and tells shell developers targeting both platforms to stay compatible with 3.9 and 3.13. Python 2.7.18 is untouched.

This also corrects setting-up-dev-env.md, which #23 had just updated to say the bundled version is 3.9.9 — accurate when it merged on Sep 6, wrong when the upgrade landed on Sep 8. That page now carries a per-platform table.

Global inputs kept when saving a sandbox as a blueprint

CS 189903 / 189905 / 189914. New KeepResourceGlobalInputsOnSaveAsBlueprint key, default true, so this is a behavior change on upgrade: global inputs that fronted a resource requirement used to be dropped and are now kept — visible in the Reserve dialog and the blueprint editor. Documented with the linked/plain-value distinction (relinked in the work-order flow, plain value where the resource was pinned down), and added to the Blueprint Workspace config keys as a Server-side customer key (AppSettingVisibility.Customer, read by ServiceConfigSettingsLoader).

Blueprint import validates categories

CS 189942. A blueprint referencing a category absent from the target domain now fails the import instead of silently dropping the association. The ExportBlueprint/ImportBlueprint page from #22 already stated this, so it needed no correction — only the release notes did.

Files

  • docs/release-notes/whats-new.md — three new 2026.1 entries
  • docs/release-notes/behavior-change.md — three rows
  • docs/admin/.../customer-configuration-keys-repository/blueprint-workspace.md — new key
  • docs/install-configure/cs-system-requirements/third-party-software.md — Python version + 2026.1 box
  • docs/devguide/setting-up-dev-env.md — per-platform bundled-Python table
  • docs/devguide/{developing-shells,develop-orch-scripts,develop-custom-cloud-provider-shells}/getting-started*.md — dev-install versions
  • .wordlist.txtCPython

npx docusaurus build passes. The 3 broken links it reports are pre-existing (intro/features/abstract-resources) and unrelated.

🤖 Generated with Claude Code

…inputs, category validation

Documents the three behavior-changing items that landed on 2026.1 after the
2026.1.0.52 pass (#18) and were not covered by #19-#22.

Python 3 upgraded to 3.13.15 x64 (Trunk CS 189988/189997/189999, backported
in CS 190003). This is the WINDOWS bundled slot only - the Docker ES image
still builds Python 3.9.9, and so do the Linux VA and the from-script ES, so
every page states the platform split rather than a blanket "CloudShell now
uses 3.13". Python 2.7.18 is untouched. Also corrects setting-up-dev-env.md,
which #23 had just updated to say the bundled version is 3.9.9 - true when
it merged on Sep 6, wrong when the upgrade landed on Sep 8.

Global inputs kept on save as blueprint, with the new
KeepResourceGlobalInputsOnSaveAsBlueprint key (CS 189903/189905/189914).
Default is true, which is a behavior change on upgrade: inputs that fronted a
resource requirement used to be dropped and are now visible in the Reserve
dialog and the blueprint editor. Documented as a customer-visible key on the
Server (AppSettingVisibility.Customer, read by ServiceConfigSettingsLoader).

Blueprint import now fails on a category missing from the target domain
instead of silently dropping the association (CS 189942). The
ExportBlueprint/ImportBlueprint page from #22 already stated this, so it
needed no correction - only the release notes did.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant