ShotGrid Toolkit core updates and shared configuration dependencies

Answer

No – a core version bump in a shared @include does not automatically cause a version mismatch in other projects that include that file.

Confirmed facts

• Each project’s pipeline_configuration.yml declares its own core_api_version (e.g., core_api_version: "v0.20.14").
• The @include directive performs a static YAML merge at parse time; it does not create a live link that propagates later changes.
• A dependent project continues to run on the core version it cached until it re‑parses its configuration (e.g., runs tank, tank updates, or tank cache_apps again).
• If the shared include contains a core_api_version key, the last‑merged value wins, which can unintentionally align versions across projects.

Steps to verify or reproduce

1. Create two projects (A and B) that both @include shared/core.yml.
2. In each project’s local pipeline_configuration.yml (after the @include) set different core_api_version values.
3. Run tank cache_apps in both projects and confirm each caches its declared core version.
4. Edit the shared core.yml to bump the core_api_version.
5. Without re‑running any Tank command in project B, check its cached core – it will still be the old version.
6. Run tank updates or tank cache_apps in project B; now it will see the new version and can cache it.

Isolating project‑specific core versions

To keep each project on its own core while still sharing other pipeline logic:

• Place core_api_version (and any frameworks or apps version pins you want fixed) in the project‑local pipeline_configuration.yml, after the @include statements.
• Avoid putting core_api_version in any shared @include file.
• If you need to share environment, templates, or settings, include those fragments only; they should not contain version pins.

Following this pattern ensures that a core version bump in a shared include only affects a project after that project explicitly refreshes its configuration and cache.