调整插件分发方式及相关文档说明

.github/workflows/release.yml

@@ -2,12 +2,12 @@
 #
 # 产出全部挂到该 Release 上,共用标签里的那个版本号:
 #
-#   velashell-plugins-<版本>.zip  主程序安装包里 plugins/ 那一层的一比一布局。
-#                                 VelaShell 主仓库发版时按 pin 的版本下载它、解进发布目录
-#                                 (见主仓库 Directory.Build.props 的 VelaPluginsBundleVersion)。
 #   *.vpx                         每个插件一份,**已签名**,供用户手工安装 / 推进插件商店。
 #   SHA256SUMS.txt                以上全部的校验和。
 #
+# 分发形态只有 .vpx 这一种:曾经还挂过一个 velashell-plugins-<版本>.zip(安装包 plugins/
+# 那一层的一比一布局,供主仓库发版时下载解开),现已不再产出。
+#
 # 本仓库**不推 nuget.org**:插件的分发形态是 .vpx 与随应用分发的 plugins/ 目录,
 # 不是 NuGet 包。要发 SDK 包请去工具链仓库 joesdu/velashell-plugin-toolchain。
 #
@@ -70,8 +70,8 @@ jobs:
           $tag = '${{ github.event.release.tag_name || inputs.tag }}'
           if ([string]::IsNullOrWhiteSpace($tag)) { Write-Error "No release tag available."; exit 1 }
           $version = $tag.TrimStart('v')
-          # 打错标签(比如 "release-2")的话,资产文件名会变成一个谁也想不到的样子,
-          # 而主仓库是按 velashell-plugins-<版本>.zip 这个确定名字去取的。
+          # 打错标签(比如 "release-2")的话,这个版本会被 Set-Version.ps1 原样写进每个
+          # plugin.json,.vpx 的文件名与宿主里显示的插件版本跟着变成一个谁也想不到的样子。
           if ($version -notmatch '^\d+\.\d+\.\d+(-[0-9A-Za-z.-]+)?$') {
             Write-Error "Release tag '$tag' does not resolve to a SemVer version (got '$version'). Use e.g. v1.4.0 or v1.4.0-preview.1."
             exit 1
@@ -130,11 +130,11 @@ jobs:
       - name: Build release assets
         shell: pwsh
         run: |
-          $version = '${{ steps.version.outputs.version }}'
           New-Item -ItemType Directory -Force artifacts/release | Out-Null
+          # plugins-bundle 不再打成 zip、也不再挂上 Release —— 它只留给下面那步
+          # "共享程序集有没有漏进去"的体检:那条检查要看的是插件目录的真实布局。
           dotnet build build/PluginBundle.proj -c Release -t:Bundle -p:BundleDir="$PWD/artifacts/plugins-bundle" --nologo
           if ($LASTEXITCODE -ne 0) { exit 1 }
-          Compress-Archive -Path artifacts/plugins-bundle/* -DestinationPath "artifacts/release/velashell-plugins-$version.zip" -Force
           # -p:VelaSigningKey 会经 MSBuild 的全局属性继承传到每个插件工程的 PackVpx 目标,
           # 由随 SDK 包分发的 vela-plugin 在打包时签名(见 PluginBundle.proj 的 PackAllVpx)。
           dotnet build build/PluginBundle.proj -c Release -t:PackAllVpx -p:VpxDir="$PWD/artifacts/vpx" -p:VelaSigningKey="$PWD/velashell-signing.pem" --nologo
@@ -202,7 +202,7 @@ jobs:
           path: artifacts/release/*
           if-no-files-found: error
 
-      # 主仓库按固定地址取 zip:releases/download/<tag>/velashell-plugins-<版本>.zip
+      # 挂上去的只有 .vpx 与 SHA256SUMS.txt。
       - name: Upload assets to release
         if: ${{ !inputs.dryRun }}
         shell: pwsh

Directory.Build.props

@@ -14,10 +14,7 @@
 
   <PropertyGroup>
     <!-- ── 本仓库的发行版本号 ─────────────────────────────────────────────────
-         第一方插件分发包(velashell-plugins-<版本>.zip)与本仓库所有插件程序集共用它。
-         VelaShell 主仓库按 Directory.Build.props 的 VelaPluginsBundleVersion pin 这个号,
-         从本仓库的 Release 资产里取那一版。
-         CI 发版时用 -p:VelaPluginsVersion= 覆盖(取自 Release 标签)。
+         本仓库所有插件程序集共用它。CI 发版时用 -p:VelaPluginsVersion= 覆盖(取自 Release 标签)。
 
          ⚠️ 它**不是** SDK 版本(见下面的 VelaSdkVersion),也**不是**单个插件的版本 ——
          后者写在各插件的 plugin.json 里,决定 .vpx 文件名与宿主看到的插件版本,

README.md

@@ -28,7 +28,7 @@ Redis、S3、Telnet,外加示例插件 HelloWorld。
 | --- | --- |
 | `plugins/` | 四个插件,一个子目录一个 csproj(见 [plugins/README.md](plugins/README.md)) |
 | `tests/` | 每个插件一个测试工程(MSTest + `VelaShell.PluginSdk.Testing` 替身) |
-| `build/PluginBundle.proj` | 发布期把可分发插件收成 `velashell-plugins-<版本>.zip`,并批量出 `.vpx` |
+| `build/PluginBundle.proj` | 批量出 `.vpx`;并把可分发插件收成 `plugins/` 布局(只用于 CI 体检) |
 | `scripts/Set-Version.ps1` | 把发行版本号写进仓库里所有落点(发版时由流水线自动跑) |
 | `Directory.Packages.props` | **中央包管理**:所有 NuGet 版本只在这一处 |
 
@@ -78,7 +78,7 @@ dotnet build plugins/VelaShell.Plugin.Redis -t:PackVpx     # 落 bin/vpx/*.vpx
 
 | 落点 | 决定什么 |
 | --- | --- |
-| `Directory.Build.props` 的 `VelaPluginsVersion` | 程序集版本、`velashell-plugins-<版本>.zip` 的文件名 |
+| `Directory.Build.props` 的 `VelaPluginsVersion` | 程序集版本 |
 | `README.md` 版本横幅 | 给人看的 |
 | 各 `plugins/*/plugin.json` 的 `version` | **`.vpx` 文件名与宿主里显示的插件版本** |
 
@@ -90,7 +90,8 @@ dotnet build plugins/VelaShell.Plugin.Redis -t:PackVpx     # 落 bin/vpx/*.vpx
 统一列车的代价是没改过的插件也跟着涨版本,用户那边会看到一次"更新";换来的是
 "这台机器上装的是哪一批插件"只有一个答案 —— 排查问题时不必逐个去问版本。
 
-主仓库按 `VelaPluginsBundleVersion` pin 这个号,从本仓库的 Release 资产里取那一版 zip。
+这个号只回答"这一批插件是哪次发布出去的";发出去的资产是每个插件各自的 `.vpx`,
+不再有整批打包的 zip。
 
 它与 SDK 版本(`VelaSdkVersion`)是两回事:SDK 发 1.5.0 不代表插件必须跟着发,
 插件发 1.4.1 也不代表契约动了。
@@ -103,7 +104,6 @@ dotnet build plugins/VelaShell.Plugin.Redis -t:PackVpx     # 落 bin/vpx/*.vpx
 2. 全量测试 + 构建;
 3. 打包并**逐个核对签名**(未签名或签名不自洽就直接失败,不会挂上去);
 4. 产出并挂到该 Release 的下载列表:
-   - `velashell-plugins-<版本>.zip` —— 包内布局就是安装包 `plugins/` 那一层,主仓库下载解开即可;
    - **每个插件一份 `.vpx`(已签名)** —— 从 Release 下载后即可手工安装,或推进插件商店;
    - `SHA256SUMS.txt`;
 5. 开一个 `chore/version-<版本>` 的 PR 把版本号回写 `main`,等你手动合。

plugins/README.md

@@ -56,12 +56,13 @@ Telnet 同理。
 
 "随包分发"由 csproj 的 `<VelaPluginShip>` 控制(默认 `true`)。示例插件设 `false`:
 本机构建仍会镜像到 `artifacts/plugins/`(以及 `VELASHELL_DEV_APP_DIR` 指定的应用目录),
-装载起来验证插件系统没问题,但它不会进 `velashell-plugins-<版本>.zip` ——
+装载起来验证插件系统没问题,但它不会被收进分发布局 ——
 它是给开发者读的范例,不是给用户装的功能。
 
-发版时由 [`build/PluginBundle.proj`](../build/PluginBundle.proj) 把 `VelaPluginShip=true`
-的插件收成一个 zip 挂到 Release,主仓库发版时下载解进安装包的 `plugins/`。
-一个可分发插件都收不到时直接失败,不会悄悄出一个空包。
+[`build/PluginBundle.proj`](../build/PluginBundle.proj) 的 `Bundle` 目标把 `VelaPluginShip=true`
+的插件收成安装包 `plugins/` 那一层的布局:它不再作为 Release 资产上传,只在 CI 与发布流水线里
+用来体检布局(尤其是共享程序集有没有漏进去)。一个可分发插件都收不到时直接失败,
+不会悄悄放过一个空布局。发出去的是每个插件各自的 `.vpx`。
 
 ## 版本号:别手改 plugin.json 的 version