Open MCT 版本管理指南语义化版本、版本发布流程与构建期版本注入实践【免费下载链接】openmctA web based mission control framework.项目地址: https://gitcode.com/GitHub_Trending/ope/openmctOpen MCT 是一个基于 Web 的任务控制mission control框架其版本号承载着发布节奏、API 兼容性承诺与插件生态兼容三重职责。本文基于仓库内 版本指南docs/src/process/version.md撰写系统讲解 Open MCT 的版本语义、版本递增规则、完整的发布操作流程并结合 构建配置 与 入口实现 说明版本信息是如何写入应用界面、服务测试人员与插件开发者的。读完本文你将掌握 Open MCT 版本号从递增决策到打标签、发 npm 包、恢复 -next 快照状态的完整闭环也能将同一套流程迁移到依赖 Open MCT 的同团队衍生项目上。版本指南在开发流程中的定位Open MCT 的开发遵循冲刺sprint 发布release的迭代节奏详见 开发周期冲刺Sprint每三周一个冲刺代表一组可完成并通过测试的改进冲刺结束时软件处于半稳定状态发布Release每四个冲刺进行一次发布发布版本经过完整的验收测试属于稳定版本。版本指南 与 开发周期、测试计划 共同构成 开发流程 的三份核心文档。版本号递增就发生在 开发周期 中描述的Ship发布这一过程点——只有通过了发布/冲刺测试的代码快照才会被打标签、被部署。版本信息的受众版本指南将消费版本号的人群划分为四类理解他们各自的需求才能明白为什么 Open MCT 要同时暴露版本号 修订标识 品牌名三份信息受众关注点典型诉求用户Users通常不关心版本偶尔需要核对用版本号对照文档或在报告问题时提供版本测试人员Testers正在测哪个版本报告缺陷时精确指出被测软件版本内部开发者Internal developers与测试人员相反确认某个行为出现在哪个版本并将版本与开发流如 dev 与 prod关联外部开发者External developers插件兼容性明确当前使用的软件版本保证自己开发的插件与之兼容版本的三重呈现方式版本指南要求软件版本在应用界面中以三种方式呈现AboutDialog.vue 的Version Information区域正是这一要求的落地实现版本号Version number语义化版本号既唯一标识某个发布也告知插件开发者与历史版本的兼容性修订标识Revision identifier使用 git 时的 commit hash通过唯一标识客户端软件快照服务内部开发者与测试人员定位问题品牌名Branding标识当前使用的是哪个变体部署到具体任务或中心时Open MCT 通常会被重新品牌化。在 AboutDialog.vue 中这些信息被渲染为ul idversionInformation classt-info l-info s-info li aria-labelVersion NumberVersion: {{ buildInfo.version || Unknown }}/li li aria-labelBuild DateBuild Date: {{ buildInfo.buildDate || Unknown }}/li li aria-labelRevisionRevision: {{ buildInfo.revision || Unknown }}/li li aria-labelBranchBranch: {{ buildInfo.branch || Unknown }}/li /ul这些buildInfo数据来源于 MCT.js 中构造器对this.buildInfo的初始化this.buildInfo { version: __OPENMCT_VERSION__, buildDate: __OPENMCT_BUILD_DATE__, revision: __OPENMCT_REVISION__, branch: __OPENMCT_BUILD_BRANCH__ };四个字段version、buildDate、revision、branch与 About 对话框中的四行展示一一对应。其中revisioncommit hash与branchgit 分支直接呼应版本指南中修订标识与开发流dev vs prod关联的诉求。构建期版本注入的底层原理__OPENMCT_VERSION__、__OPENMCT_REVISION__等并非运行时变量而是由 webpack 的DefinePlugin在构建期注入的编译常量。webpack.common.mjs 是它们的定义来源new webpack.DefinePlugin({ __OPENMCT_VERSION__: ${version}, __OPENMCT_BUILD_DATE__: ${new Date()}, __OPENMCT_REVISION__: ${gitRevision}, __OPENMCT_BUILD_BRANCH__: ${gitBranch}, __VUE_OPTIONS_API__: true, __VUE_PROD_DEVTOOLS__: false, ... })其中version在构建脚本启动时从根目录 package.json 读取JSON.parse(fs.readFileSync(new URL(../package.json, import.meta.url)))当前仓库快照的版本为4.2.0-next正是开发期带-next后缀的典型形态gitRevision与gitBranch通过git rev-parse HEAD与git rev-parse --abbrev-ref HEAD实时获取见 webpack.common.mjs因此每次构建产出的revision都能精确对应一个源码快照——这正好实现版本指南中用 commit hash 唯一标识客户端软件快照的目标。这一机制意味着版本号变更只需修改package.json无需改动任何业务代码重新构建即可把新版本注入到界面的 About 对话框中。语义化版本规范Open MCT 的版本号遵循 Semantic Versioning 2.0.0语义化版本 2.0.0。核心规则如下版本以major.minor.patch三段式表达破坏性变更Breaking changes递增major主版本号向后兼容的新功能Backwards-compatible changes递增minor次版本号中性变更如缺陷修复递增patch修订号预发布版本以连字符分隔的后缀标识可能不稳定或不能完全满足兼容性要求。Open MCT 项目特有版本标准在语义化版本的基础上版本指南补充了三条项目级约定1. 开发期使用-next后缀开发过程中版本号需附加-next后缀前缀数字应反映下一个预期发布的版本号。例如当前仓库 package.json 中的4.2.0-next表示下一个稳定版本预期为4.2.0当前正处于其开发阶段。2. 1.0.0 之前的递增节奏在发布 1.0.0 之前minor按每次发布递增patch按每个冲刺递增。3. 1.0.0 之后的递增节奏从 1.0.0 开始每个完成的冲刺都要更新版本号。具体版本号依据与上一个已发布版本的对比来确定根据该发布期间变更的性质决定递增 major、minor 还是 patch。指南建议在变更引入时就逐步递增这些数字这样在发布结束时只需移除后缀即可得到最终版本号避免临发布前集中决策带来的风险。4. 发布前三个冲刺的稳定性后缀一个发布周期的前三个冲刺可能不稳定此时仍需生成唯一的版本标识但应附带后缀以表明该版本不一定具备生产就绪性。推荐后缀如下冲刺推荐后缀1-alpha2-beta3-rc外部 API 的界定范围版本指南特别澄清外部 API指暴露给、文档化给并被插件开发者使用的 API。仅影响 Open MCT 内部使用或未对外文档化的接口变更只需递增patch版本号即可。这一界定决定了 major/minor 递增的触发条件是插件生态下语义化版本能否如实地传达兼容性信息的关键。版本递增与发布操作流程冲刺结束时项目经理project manager应按下述流程更新或委托他人更新Open MCT 版本号。该角色在 开发周期 中有明确定义若无专职项目经理可在团队内按冲刺轮换。第 1 步更新 package.json 中的版本号检出上一个已成功通过测试的冲刺所创建的分支移除 package.json 中版本的-next后缀校验得到的版本号相对于上一个稳定版本满足语义化版本要求必要时递增版本号若该版本被认为不稳定比如处于一个发布周期的前三个冲刺按上文 版本递增规则 附加新后缀-alpha/-beta/-rc。第 2 步给发布打标签Tag在上一分支上提交 package.json 的变更提交信息应引用被关闭的冲刺最好通过 URL 引用 GitHub 上关联的 Milestone验证构建仍能完成、应用通过冒烟测试且与已测试版本的差异仅限于上述版本号变更推送新分支用版本号给该提交打标签前缀字母v例如git tag v0.9.3-alpha推送标签到 GitHub例如git push origin v0.9.3-alpha。第 3 步上传发布归档Release Archive使用 GitHub release 界面起草新发布选择上一步创建并推送的现有标签将标签名同时作为发布名称参考现有发布格式如Open MCT v0.9.3-alpha视情况将发布标记为pre-release例如版本号带不稳定后缀时或版本号低于 1.0.0 时撰写发布说明Release Notes简述破坏性变更、增强与缺陷修复及其解决方案发布该版本。第 4 步发布到 npm登录 npm检出上一步创建的标签在 package.json 中将包改为公开private: false。注意当前仓库的根 package.json 并未显式声明private字段且配置了workspaces: [e2e]发布前需要确认包的公开访问属性发布前可用npm publish --dry-run试跑测试包内容将包发布到 npmjs registry例如npm publish --access public。注意若为预发布版本需给 npm publish 加上--tag unstable标志确认包已成功发布例如在 npmjs 上查看openmct包。第 5 步在 package.json 中恢复快照状态Snapshot Status发布完成并非流程终点还需要让主干分支回到开发中状态基于master分支创建新分支移除版本号上的后缀若无后缀则递增 patch 版本追加-next后缀例如4.2.0→4.2.0-next在master分支上提交 package.json 的变更提交信息应引用被开启的冲刺最好通过 URL 引用 GitHub 上关联的 Milestone验证构建仍能完成、应用通过冒烟测试创建 PR 合并回master分支。这一去后缀 → 打标签发布 → 再补-next后缀的循环正是当前仓库快照中4.2.0-next这个版本号之所以存在的直接原因也保证了任何时候master上的版本号都明确表达当前开发指向的下一个发布版本。完整发布流程速查表阶段关键动作示例命令更新版本移除-next必要时递增并加不稳定后缀编辑package.json的version字段打标签提交、验证、推送并打v前缀标签git tag v0.9.3-alpha发布归档起草 GitHub Release勾选 pre-release发布名如Open MCT v0.9.3-alpha发布 npm设公开、dry-run、正式发布npm publish --access public预发布加--tag unstable恢复快照递增 patch 或去后缀再附-next4.2.0→4.2.0-next依赖项目的协同版本流程版本指南的最后一部分针对由 Open MCT 团队协同开发、且依赖 Open MCT 的项目这类项目应遵循与 Open MCT 自身相似的流程但有两处额外动作在移除自身的-next状态时同时把对 Open MCT 的依赖更新到最新归档版本即上一步发布的正式版本上述工作完成后将对 Open MCT 的依赖指回master分支从而在下一次发布前持续跟随主干开发。这套协同机制保证了同团队多项目之间的版本对齐子项目发布时依赖的是已发布、可追溯的 Open MCT 版本而日常开发中又不会因依赖锁死而阻塞跟进 Open MCT 的最新变更。在仓库中验证版本信息读者可以在当前仓库中直接验证本文描述的机制查看 package.json 的nameopenmct与version4.2.0-next字段确认开发快照形态阅读 webpack.common.mjs 中版本、构建日期、git 修订与分支的注入逻辑理解改package.json即改界面版本号对比 MCT.js 的buildInfo初始化与 AboutDialog.vue 的渲染确认版本号 修订标识 品牌三重呈现的实际落点若需执行构建以观察注入效果可运行npm run build:dev开发构建或npm run build:prod生产构建构建产物dist/openmct.js中的__OPENMCT_VERSION__等常量会被替换为当前 package.json 中的真实值Node 版本要求见 package.json 的engines.node 24.14.1。小结Open MCT 的版本管理是一套把语义化版本 开发节奏 发布操作 构建注入串联起来的完整流程major/minor/patch的递增决策由 开发周期 的冲刺节奏驱动-next、-alpha、-beta、-rc后缀在界面与 npm 包中同时标识稳定性v前缀的 git 标签与 GitHub Release 承载可追溯的发布历史而 webpack.common.mjs 的DefinePlugin把 package.json 中的版本号连同 commit hash、分支与构建日期一起注入 AboutDialog.vue 的界面展示。对插件开发者而言理解外部 API的界定即可快速判断某个变更是否需要关注 major 递增对同团队依赖项目则可直接复用这套流程并同步维护对 Open MCT 的依赖指向。【免费下载链接】openmctA web based mission control framework.项目地址: https://gitcode.com/GitHub_Trending/ope/openmct创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Open MCT 版本管理指南：语义化版本、版本发布流程与构建期版本注入实践
Open MCT 版本管理指南语义化版本、版本发布流程与构建期版本注入实践【免费下载链接】openmctA web based mission control framework.项目地址: https://gitcode.com/GitHub_Trending/ope/openmctOpen MCT 是一个基于 Web 的任务控制mission control框架其版本号承载着发布节奏、API 兼容性承诺与插件生态兼容三重职责。本文基于仓库内 版本指南docs/src/process/version.md撰写系统讲解 Open MCT 的版本语义、版本递增规则、完整的发布操作流程并结合 构建配置 与 入口实现 说明版本信息是如何写入应用界面、服务测试人员与插件开发者的。读完本文你将掌握 Open MCT 版本号从递增决策到打标签、发 npm 包、恢复 -next 快照状态的完整闭环也能将同一套流程迁移到依赖 Open MCT 的同团队衍生项目上。版本指南在开发流程中的定位Open MCT 的开发遵循冲刺sprint 发布release的迭代节奏详见 开发周期冲刺Sprint每三周一个冲刺代表一组可完成并通过测试的改进冲刺结束时软件处于半稳定状态发布Release每四个冲刺进行一次发布发布版本经过完整的验收测试属于稳定版本。版本指南 与 开发周期、测试计划 共同构成 开发流程 的三份核心文档。版本号递增就发生在 开发周期 中描述的Ship发布这一过程点——只有通过了发布/冲刺测试的代码快照才会被打标签、被部署。版本信息的受众版本指南将消费版本号的人群划分为四类理解他们各自的需求才能明白为什么 Open MCT 要同时暴露版本号 修订标识 品牌名三份信息受众关注点典型诉求用户Users通常不关心版本偶尔需要核对用版本号对照文档或在报告问题时提供版本测试人员Testers正在测哪个版本报告缺陷时精确指出被测软件版本内部开发者Internal developers与测试人员相反确认某个行为出现在哪个版本并将版本与开发流如 dev 与 prod关联外部开发者External developers插件兼容性明确当前使用的软件版本保证自己开发的插件与之兼容版本的三重呈现方式版本指南要求软件版本在应用界面中以三种方式呈现AboutDialog.vue 的Version Information区域正是这一要求的落地实现版本号Version number语义化版本号既唯一标识某个发布也告知插件开发者与历史版本的兼容性修订标识Revision identifier使用 git 时的 commit hash通过唯一标识客户端软件快照服务内部开发者与测试人员定位问题品牌名Branding标识当前使用的是哪个变体部署到具体任务或中心时Open MCT 通常会被重新品牌化。在 AboutDialog.vue 中这些信息被渲染为ul idversionInformation classt-info l-info s-info li aria-labelVersion NumberVersion: {{ buildInfo.version || Unknown }}/li li aria-labelBuild DateBuild Date: {{ buildInfo.buildDate || Unknown }}/li li aria-labelRevisionRevision: {{ buildInfo.revision || Unknown }}/li li aria-labelBranchBranch: {{ buildInfo.branch || Unknown }}/li /ul这些buildInfo数据来源于 MCT.js 中构造器对this.buildInfo的初始化this.buildInfo { version: __OPENMCT_VERSION__, buildDate: __OPENMCT_BUILD_DATE__, revision: __OPENMCT_REVISION__, branch: __OPENMCT_BUILD_BRANCH__ };四个字段version、buildDate、revision、branch与 About 对话框中的四行展示一一对应。其中revisioncommit hash与branchgit 分支直接呼应版本指南中修订标识与开发流dev vs prod关联的诉求。构建期版本注入的底层原理__OPENMCT_VERSION__、__OPENMCT_REVISION__等并非运行时变量而是由 webpack 的DefinePlugin在构建期注入的编译常量。webpack.common.mjs 是它们的定义来源new webpack.DefinePlugin({ __OPENMCT_VERSION__: ${version}, __OPENMCT_BUILD_DATE__: ${new Date()}, __OPENMCT_REVISION__: ${gitRevision}, __OPENMCT_BUILD_BRANCH__: ${gitBranch}, __VUE_OPTIONS_API__: true, __VUE_PROD_DEVTOOLS__: false, ... })其中version在构建脚本启动时从根目录 package.json 读取JSON.parse(fs.readFileSync(new URL(../package.json, import.meta.url)))当前仓库快照的版本为4.2.0-next正是开发期带-next后缀的典型形态gitRevision与gitBranch通过git rev-parse HEAD与git rev-parse --abbrev-ref HEAD实时获取见 webpack.common.mjs因此每次构建产出的revision都能精确对应一个源码快照——这正好实现版本指南中用 commit hash 唯一标识客户端软件快照的目标。这一机制意味着版本号变更只需修改package.json无需改动任何业务代码重新构建即可把新版本注入到界面的 About 对话框中。语义化版本规范Open MCT 的版本号遵循 Semantic Versioning 2.0.0语义化版本 2.0.0。核心规则如下版本以major.minor.patch三段式表达破坏性变更Breaking changes递增major主版本号向后兼容的新功能Backwards-compatible changes递增minor次版本号中性变更如缺陷修复递增patch修订号预发布版本以连字符分隔的后缀标识可能不稳定或不能完全满足兼容性要求。Open MCT 项目特有版本标准在语义化版本的基础上版本指南补充了三条项目级约定1. 开发期使用-next后缀开发过程中版本号需附加-next后缀前缀数字应反映下一个预期发布的版本号。例如当前仓库 package.json 中的4.2.0-next表示下一个稳定版本预期为4.2.0当前正处于其开发阶段。2. 1.0.0 之前的递增节奏在发布 1.0.0 之前minor按每次发布递增patch按每个冲刺递增。3. 1.0.0 之后的递增节奏从 1.0.0 开始每个完成的冲刺都要更新版本号。具体版本号依据与上一个已发布版本的对比来确定根据该发布期间变更的性质决定递增 major、minor 还是 patch。指南建议在变更引入时就逐步递增这些数字这样在发布结束时只需移除后缀即可得到最终版本号避免临发布前集中决策带来的风险。4. 发布前三个冲刺的稳定性后缀一个发布周期的前三个冲刺可能不稳定此时仍需生成唯一的版本标识但应附带后缀以表明该版本不一定具备生产就绪性。推荐后缀如下冲刺推荐后缀1-alpha2-beta3-rc外部 API 的界定范围版本指南特别澄清外部 API指暴露给、文档化给并被插件开发者使用的 API。仅影响 Open MCT 内部使用或未对外文档化的接口变更只需递增patch版本号即可。这一界定决定了 major/minor 递增的触发条件是插件生态下语义化版本能否如实地传达兼容性信息的关键。版本递增与发布操作流程冲刺结束时项目经理project manager应按下述流程更新或委托他人更新Open MCT 版本号。该角色在 开发周期 中有明确定义若无专职项目经理可在团队内按冲刺轮换。第 1 步更新 package.json 中的版本号检出上一个已成功通过测试的冲刺所创建的分支移除 package.json 中版本的-next后缀校验得到的版本号相对于上一个稳定版本满足语义化版本要求必要时递增版本号若该版本被认为不稳定比如处于一个发布周期的前三个冲刺按上文 版本递增规则 附加新后缀-alpha/-beta/-rc。第 2 步给发布打标签Tag在上一分支上提交 package.json 的变更提交信息应引用被关闭的冲刺最好通过 URL 引用 GitHub 上关联的 Milestone验证构建仍能完成、应用通过冒烟测试且与已测试版本的差异仅限于上述版本号变更推送新分支用版本号给该提交打标签前缀字母v例如git tag v0.9.3-alpha推送标签到 GitHub例如git push origin v0.9.3-alpha。第 3 步上传发布归档Release Archive使用 GitHub release 界面起草新发布选择上一步创建并推送的现有标签将标签名同时作为发布名称参考现有发布格式如Open MCT v0.9.3-alpha视情况将发布标记为pre-release例如版本号带不稳定后缀时或版本号低于 1.0.0 时撰写发布说明Release Notes简述破坏性变更、增强与缺陷修复及其解决方案发布该版本。第 4 步发布到 npm登录 npm检出上一步创建的标签在 package.json 中将包改为公开private: false。注意当前仓库的根 package.json 并未显式声明private字段且配置了workspaces: [e2e]发布前需要确认包的公开访问属性发布前可用npm publish --dry-run试跑测试包内容将包发布到 npmjs registry例如npm publish --access public。注意若为预发布版本需给 npm publish 加上--tag unstable标志确认包已成功发布例如在 npmjs 上查看openmct包。第 5 步在 package.json 中恢复快照状态Snapshot Status发布完成并非流程终点还需要让主干分支回到开发中状态基于master分支创建新分支移除版本号上的后缀若无后缀则递增 patch 版本追加-next后缀例如4.2.0→4.2.0-next在master分支上提交 package.json 的变更提交信息应引用被开启的冲刺最好通过 URL 引用 GitHub 上关联的 Milestone验证构建仍能完成、应用通过冒烟测试创建 PR 合并回master分支。这一去后缀 → 打标签发布 → 再补-next后缀的循环正是当前仓库快照中4.2.0-next这个版本号之所以存在的直接原因也保证了任何时候master上的版本号都明确表达当前开发指向的下一个发布版本。完整发布流程速查表阶段关键动作示例命令更新版本移除-next必要时递增并加不稳定后缀编辑package.json的version字段打标签提交、验证、推送并打v前缀标签git tag v0.9.3-alpha发布归档起草 GitHub Release勾选 pre-release发布名如Open MCT v0.9.3-alpha发布 npm设公开、dry-run、正式发布npm publish --access public预发布加--tag unstable恢复快照递增 patch 或去后缀再附-next4.2.0→4.2.0-next依赖项目的协同版本流程版本指南的最后一部分针对由 Open MCT 团队协同开发、且依赖 Open MCT 的项目这类项目应遵循与 Open MCT 自身相似的流程但有两处额外动作在移除自身的-next状态时同时把对 Open MCT 的依赖更新到最新归档版本即上一步发布的正式版本上述工作完成后将对 Open MCT 的依赖指回master分支从而在下一次发布前持续跟随主干开发。这套协同机制保证了同团队多项目之间的版本对齐子项目发布时依赖的是已发布、可追溯的 Open MCT 版本而日常开发中又不会因依赖锁死而阻塞跟进 Open MCT 的最新变更。在仓库中验证版本信息读者可以在当前仓库中直接验证本文描述的机制查看 package.json 的nameopenmct与version4.2.0-next字段确认开发快照形态阅读 webpack.common.mjs 中版本、构建日期、git 修订与分支的注入逻辑理解改package.json即改界面版本号对比 MCT.js 的buildInfo初始化与 AboutDialog.vue 的渲染确认版本号 修订标识 品牌三重呈现的实际落点若需执行构建以观察注入效果可运行npm run build:dev开发构建或npm run build:prod生产构建构建产物dist/openmct.js中的__OPENMCT_VERSION__等常量会被替换为当前 package.json 中的真实值Node 版本要求见 package.json 的engines.node 24.14.1。小结Open MCT 的版本管理是一套把语义化版本 开发节奏 发布操作 构建注入串联起来的完整流程major/minor/patch的递增决策由 开发周期 的冲刺节奏驱动-next、-alpha、-beta、-rc后缀在界面与 npm 包中同时标识稳定性v前缀的 git 标签与 GitHub Release 承载可追溯的发布历史而 webpack.common.mjs 的DefinePlugin把 package.json 中的版本号连同 commit hash、分支与构建日期一起注入 AboutDialog.vue 的界面展示。对插件开发者而言理解外部 API的界定即可快速判断某个变更是否需要关注 major 递增对同团队依赖项目则可直接复用这套流程并同步维护对 Open MCT 的依赖指向。【免费下载链接】openmctA web based mission control framework.项目地址: https://gitcode.com/GitHub_Trending/ope/openmct创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考