.vpx 版本跟随 Release 标签:把 plugin.json 的 version 也纳入版本落点

.github/workflows/release.yml

@@ -20,13 +20,14 @@
 #   契约程序集(宿主已签名,不能引用未签名程序集),本仓库不产出程序集包,不参与那条约束。
 #
 # 📌 版本号不用手工改:标签解析出来之后,流水线**第一件事**就是跑
-#    scripts/Set-Version.ps1 把该版本写进 Directory.Build.props 与 README 版本横幅。
-#    发布成功后由 sync-main 任务开一个 PR 把这些改动回写 main(等你手动合)。
-#    所以发版只剩两步:合进 main → 在 GitHub 上发 Release,标签填 v<版本>。
+#    scripts/Set-Version.ps1,把该版本写进 Directory.Build.props、README 版本横幅,
+#    以及**每个 plugins/*/plugin.json 的 version**。发布成功后由 sync-main 任务开一个
+#    PR 把这些改动回写 main(等你手动合)。所以发版只剩两步:
+#    合进 main → 在 GitHub 上发 Release,标签填 v<版本>。
 #
-# ⚠️ 单个插件的版本在各自的 plugin.json 里,本流水线**不碰**。要发新版 Redis,
-#    改 plugins/VelaShell.Plugin.Redis/plugin.json 的 version 并合进 main,
-#    下一次 Release 出的 velashell.redis-*.vpx 自然就是新版本号。
+# ⚠️ 本仓库是一趟**统一发布列车**:一次 Release,所有插件同上一个版本号,没有
+#    "只发新版 Redis"这回事。plugin.json 的 version 决定 .vpx 文件名与宿主里显示的
+#    插件版本,它由本流水线覆盖 —— 手改它没有意义,下次发版会被标签里的版本盖回去。
 name: Release
 
 on:

Directory.Build.props

@@ -22,7 +22,7 @@
          ⚠️ 它**不是** SDK 版本(见下面的 VelaSdkVersion),也**不是**单个插件的版本 ——
          后者写在各插件的 plugin.json 里,决定 .vpx 文件名与宿主看到的插件版本,
          各插件各自演进,互不牵连。这里这个号只回答"这一批插件是哪次发布出去的"。 -->
-    <VelaPluginsVersion Condition="'$(VelaPluginsVersion)' == ''">1.0.0</VelaPluginsVersion>
+    <VelaPluginsVersion Condition="'$(VelaPluginsVersion)' == ''">1.4.0</VelaPluginsVersion>
     <!-- 去掉预发布后缀的数字版(AssemblyVersion/FileVersion 不接受后缀)。 -->
     <VelaPluginsVersionCore>$([System.Text.RegularExpressions.Regex]::Replace($(VelaPluginsVersion), '-.*$', ''))</VelaPluginsVersionCore>
     <Version>$(VelaPluginsVersion)</Version>

README.md

@@ -1,6 +1,6 @@
 # VelaShell 第一方插件
 
-> 当前版本 **1.0.0** · SDK **1.4.0**
+> 当前版本 **1.4.0** · SDK **1.4.0**
 
 [VelaShell](https://github.com/joesdu/VelaShell) 官方维护的插件,一个解决方案管起来:
 Redis、S3、Telnet,外加示例插件 HelloWorld。
@@ -71,15 +71,28 @@ dotnet build plugins/VelaShell.Plugin.Redis -t:PackVpx     # 落 bin/vpx/*.vpx
 然后打开本仓库 [`nuget.config`](nuget.config) 里那条注释掉的本地源,再
 `dotnet build -p:VelaSdkVersion=1.5.0-dev`。用完记得把本地源注释回去再提交。
 
-## 两个版本号,别混
+## 版本号:一趟统一列车
 
-- **插件自己的版本**在各自的 `plugin.json` 里,各插件独立演进,决定 `.vpx` 文件名
-  与宿主看到的插件版本。
-- **本仓库的发行版本**(`Directory.Build.props` 的 `VelaPluginsVersion`)只回答
-  "这一批插件是哪次发布出去的"。主仓库按它 pin(`VelaPluginsBundleVersion`),
-  从本仓库的 Release 资产里取那一版 zip。
+本仓库的插件**同上同下** —— 一次 Release,所有插件都是那个版本号。Release 标签是唯一
+的输入,`scripts/Set-Version.ps1` 把它写进三处:
 
-它与 SDK 版本(`VelaSdkVersion`)也是两回事:SDK 发 1.5.0 不代表插件必须跟着发,
+| 落点 | 决定什么 |
+| --- | --- |
+| `Directory.Build.props` 的 `VelaPluginsVersion` | 程序集版本、`velashell-plugins-<版本>.zip` 的文件名 |
+| `README.md` 版本横幅 | 给人看的 |
+| 各 `plugins/*/plugin.json` 的 `version` | **`.vpx` 文件名与宿主里显示的插件版本** |
+
+最后那一处最容易漏:打包器出的是 `<id>-<plugin.json 的 version>.vpx`,与 MSBuild 那边的
+`VelaPluginsVersion` **毫无关系** —— 只改前者的话,发 1.4.0 出来的仍旧叫
+`velashell.redis-0.1.0.vpx`。脚本会动态枚举 `plugins/` 下的每个 `plugin.json`,
+新增插件时不用回来改它。
+
+统一列车的代价是没改过的插件也跟着涨版本,用户那边会看到一次"更新";换来的是
+"这台机器上装的是哪一批插件"只有一个答案 —— 排查问题时不必逐个去问版本。
+
+主仓库按 `VelaPluginsBundleVersion` pin 这个号,从本仓库的 Release 资产里取那一版 zip。
+
+它与 SDK 版本(`VelaSdkVersion`)是两回事:SDK 发 1.5.0 不代表插件必须跟着发,
 插件发 1.4.1 也不代表契约动了。
 
 ## 发布

VelaShell.Plugins.slnx

@@ -21,7 +21,6 @@
     <File Path="plugins/Directory.Build.props" />
     <File Path="plugins/Directory.Build.targets" />
     <File Path="plugins/README.md" />
-    <Project Path="plugins/VelaShell.Plugin.HelloWorld/VelaShell.Plugin.HelloWorld.csproj" />
     <Project Path="plugins/VelaShell.Plugin.Redis/VelaShell.Plugin.Redis.csproj" />
     <Project Path="plugins/VelaShell.Plugin.S3/VelaShell.Plugin.S3.csproj" />
     <Project Path="plugins/VelaShell.Plugin.Telnet/VelaShell.Plugin.Telnet.csproj" />
@@ -30,7 +29,6 @@
     <File Path="tests/Directory.Build.props" />
     <File Path="tests/Directory.Build.targets" />
     <File Path="tests/velashell.runsettings" />
-    <Project Path="tests/VelaShell.Plugin.HelloWorld.Tests/VelaShell.Plugin.HelloWorld.Tests.csproj" />
     <Project Path="tests/VelaShell.Plugin.Redis.Tests/VelaShell.Plugin.Redis.Tests.csproj" />
     <Project Path="tests/VelaShell.Plugin.S3.Tests/VelaShell.Plugin.S3.Tests.csproj" />
     <Project Path="tests/VelaShell.Plugin.Telnet.Tests/VelaShell.Plugin.Telnet.Tests.csproj" />

plugins/README.md

@@ -63,13 +63,19 @@ Telnet 同理。
 的插件收成一个 zip 挂到 Release,主仓库发版时下载解进安装包的 `plugins/`。
 一个可分发插件都收不到时直接失败,不会悄悄出一个空包。
 
-## 版本号:两个,别混
+## 版本号:别手改 plugin.json 的 version
 
-- **插件自己的版本**写在各自的 `plugin.json` 里,决定 `.vpx` 文件名与宿主看到的版本。
-  各插件各自演进 —— Redis 发 0.2.0 与 Telnet 没有关系。
-- **本仓库的发行版本**(根 `Directory.Build.props` 的 `VelaPluginsVersion`)只回答
-  "这一批插件是哪次发布出去的",用于 `velashell-plugins-<版本>.zip` 的文件名与
-  程序集版本;主仓库按它 pin(`VelaPluginsBundleVersion`)。
+本仓库是一趟**统一发布列车** —— 一次 Release,所有插件同上一个版本号,由
+[`scripts/Set-Version.ps1`](../scripts/Set-Version.ps1) 从 Release 标签写进
+`Directory.Build.props`、README 横幅,以及**每个 `plugin.json` 的 `version`**。
+
+所以新增插件时 `plugin.json` 里那个 `version` 填什么都行(填 `0.1.0` 即可),
+下一次发版会被覆盖掉;**别为了"发个新版 Redis"去手改它** —— 改了也只会在下次发版时
+被标签里的版本盖回去,徒增一次无意义的 diff。
+
+要点在于:`.vpx` 的文件名是 `<id>-<plugin.json 的 version>.vpx`,
+与 MSBuild 的 `VelaPluginsVersion` 毫无关系。两处必须一起写,只写一处就会出现
+"发了 1.4.0,包却叫 velashell.redis-0.1.0.vpx"。
 
 ## 规划中(尚未创建)