From 9b7be5f660d7a54eb994fb0d23375c76c73edf4b Mon Sep 17 00:00:00 2001 From: Jie Date: Sun, 6 Sep 2026 01:38:35 +0800 Subject: [PATCH] Say when an integration syncs Core, and why not sooner The rule was implied by two scripts and written down nowhere: an integration syncs as part of its own release, because a repository that re-syncs when Core publishes has aligned its source and nothing a user can install. --- docs/projects.md | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/docs/projects.md b/docs/projects.md index 11f1c3c..b244817 100644 --- a/docs/projects.md +++ b/docs/projects.md @@ -59,6 +59,19 @@ Platform plugins depend on Core. Core must not depend on platform plugins. Core changes flow into plugin repositories by copying or packaging `dist/` assets. Plugin changes should not require Core version changes unless they alter the Core API or assets. +**An integration syncs Core as part of its own release, not when Core ships.** +A vendored copy cannot follow Core in real time: every artifact freezes the +snapshot it was built from — a `.vsix`, a plugin zip, and the source archive +GitHub attaches to a tag alike — so a repository that re-syncs the moment Core +publishes has aligned its source and nothing a user can install. Alignment is +something a release does. + +So `tools/check-core-freshness.mjs` is advisory day to day and strict at the +packaging gate: being behind between releases is reported, and nothing can be +packaged from a stale engine (`--strict`, wired into each integration's build +or packaging script). A security-grade Core release is the case that should not +wait for the next feature release — cut the integration release for it. + ## Repository Split | Repository | Intended channel | Licence | Available from today |