[xen2]

Why

The content templates (Stride.Templates.Samples, .Games.Starters, .AssetPacks) hold samples that rarely change, and they are big:

	Packed (.nupkg)	Extracted	NuGet cache (both)
Samples	132 MB	211 MB	344 MB
Starters	104 MB	221 MB	327 MB
AssetPacks	19 MB	40 MB	59 MB
Total	255 MB	472 MB	730 MB

For comparison, the engine-versioned Stride.Templates.Games is 2 MB packed. Until now the content packs were hard to control:

• Their version was derived from the engine. It was SamplesVersion plus the engine's prerelease suffix, so every engine beta asked for a new content version. A 4.5 beta engine asked for 4.4.0-betaN content: old content from the 4.4 cycle, or nothing.
• Every build packed them. Each worktree produced its own -devN copy of the whole content on every build, and every engine release packed them again.
• Releases relied on luck. The engine release re-packed the content under the same version and pushed it with -SkipDuplicate. That only works if the samples did not change. If they did, nuget.org silently kept the old packages and nobody noticed.

What changes

• One exact content version. StrideVersion.SamplesVersion is the exact published version the engine uses, with no suffix added. Game Studio pins it ([x.y.z]), and the Game Studio bridge and the stride CLI share one resolver for it. The same content is reused by any number of engine releases. Every lookup is exact: no "this version or higher" when resolving or downloading, and the CLI also uses the exact Stride.Templates.Games its engine depends on.
• Normal builds don't pack the content. To pack this checkout's samples while working on them, set StridePackContentTemplates to true in build/Stride.Local.props (new files have the line commented out; add it to an existing one), or pass -p:StridePackContentTemplates=true for a one-off build. The pack is always -devN (4.4.0-beta7-dev2) and is preferred locally; the next build with the flag off removes it. A dev build copies only that dev pack from local feeds into the NuGet cache, so a local file carrying a published version no longer replaces the published package (the build warns about such files). CI builds pack them by default, so CI still tests the samples of the branch and does not need the content to be published.
• Game Studio never downloads at startup. Installed content is used right away; a missing Starters or Samples package downloads in the background and its templates appear in the open New Project window once ready, with the download shown in the window. AssetPacks download when the New Game options first need them; the options window opens right away and shows the download.
• A samples release is its own workflow, and the branch never names unpublished content. Sample changes are merged like any other change. release-samples.yml packs them under the next content version, tests, signs and publishes them, tags samples/<version>, and only then commits SamplesVersion to the branch. Nothing is committed on a dry run. PrepareSamplesForRelease (in build/Stride.Samples.build) runs the upgraders over the samples and packs them locally, for when the engine changed under them. The steps are in docs/build/versioning.md.
• Warnings and guards.
  • A PR that changes the samples gets a warning on the changed file, as a reminder that a samples release is pending.
  • release-samples.yml refuses a version that is not after the committed one, is already released, is not on the branch's engine line (4.4.x content is released from the 4.4 branch only), or is prerelease for a stable engine. An empty version takes the next number, or <line>.0 when the branch still names older-line content.
  • The engine deploy refuses to release when the content it names is not on nuget.org, or when a stable engine names prerelease content.
  • The engine deploy warns, with the file list, when the samples changed since the published content. The engine still ships with the published content, which is fine for work not released yet.
• Older content is upgraded on New Project. Content packed for an older engine keeps its version when instantiated, so the package upgraders run on it when the project loads.
• Fixes found along the way.
  • SharedAssemblyInfo.Generated.cs was regenerated only when the engine version changed, so a changed SamplesVersion never reached the build. It now regenerates on any change to SharedAssemblyInfo.cs.
  • stride new reports a failed project upgrade instead of exiting with success.
  • The stride CLI's template profile added the same packages again on every run and kept old versions installed next to the current ones. It now installs from the extracted package and keeps only the packages resolved for the run.

SamplesVersion is 4.4.0-beta7 on this branch: the content already published with that engine, and the samples are unchanged since. Dev builds keep working right after the merge.

After merge

1. Merge forward to master. GitHub only offers to run a workflow once it is on the default branch.
2. Run release-samples.yml on master-4.4 with deploy on, an empty version (it takes 4.4.0), and the version-suffix of the next engine release. It publishes 4.4.0 and commits SamplesVersion = "4.4.0". This is needed before the 4.4.0 stable engine release, since a stable engine must not name 4.4.0-beta7.
3. Merge that commit forward to master too.

Testing

• Built Game Studio and Stride.Cli; unit tests for the exact version rules (TestContentTemplateResolver).
• Ran PrepareSamplesForRelease end to end (before its number handling moved to the workflow).
• Checked that content packs are produced only with the flag, from the command line or build/Stride.Local.props, and that a build with the flag off removes them (also from VS's up-to-date check).
• Checked that the Game Studio nuspec pins Starters and Samples to the exact version.
• Ran the workflow scripts locally: version selection (PowerShell 7), the engine deploy check (with temporary local tags), and the PR warning.
• Ran release-samples.yml on a fork without signing or publishing: version choice, pack, package check and smoke test passed.
• In Game Studio:
  • Created a sample, a starter and an empty game.
  • With the content packages removed from the NuGet cache, Game Studio opened right away and downloaded them in the background, with the progress shown; the New Game options showed the AssetPacks download, then the packs.
  • Offline: Game Studio opened with a "could not download" line, and New Game offered no packs.
  • With StridePackContentTemplates on, the -devN pack was used; turning it off and building removed it, and the published content was used again.
  • With the engine patch set to 1, a starter from the 4.4.0-beta7 content was upgraded to 4.4.1-dev4 on load.
• stride CLI: listed and created templates for a dev engine, the published 4.4.0-beta7 engine (from before the pinning), a dev engine with the old version scheme, and 4.3; checked the template profile after repeated runs.
• Not tested yet: the publish part of release-samples.yml (needs the real secrets).

[github-actions]

🤖 Draft PR — automatic CI is skipped to save runner minutes.

• Mark the PR ready for review to run the full automatic CI — or add a ci-run-on-draft label to run it now without leaving draft.
• Or arm a specific opt-in suite: ci-enduser, ci-editor, ci-ios, ci-android.

[Kryptos-FR]

@xen2 I pushed a commit to fix the Launcher build.