Huly 版本标签 v* 与 s* 的区别如何选择部署版本【免费下载链接】platformHuly — All-in-One Project Management Platform (alternative to Linear, Jira, Slack, Notion, Motion)项目地址: https://gitcode.com/GitHub_Trending/platform80/platform在 HulyHuly Platform一体化项目管理平台中准备部署或升级时你会在发布渠道里看到两类版本标签v*与s*例如v0.7.310、v0.6.501与s0.7.313、s0.7.288。选错类型意味着把未经验证的构建直接拉进生产或者反过来在生产里用着缺少正式发布说明的开发版。这篇文章基于仓库内 README.md 的 Versions 章节、changelog.md 与 CI 工作流说明两类标签的区别以及按部署用途选择版本并核对所选版本的方法。v* 与 s* 两类版本标签的定义Huly Platform 使用两种版本标签来区分生产就绪版本与开发版本来源README.md 的 Versions 章节标签定位示例发布说明适用场景v*Production Versions面向最终用户的稳定版本v0.7.310、v0.7.307、v0.6.501随 GitHub Releases 附带 release notes推荐用于生产部署适合 self-hosted 安装s*Development Versions面向开发者的预发布构建s0.7.313、s0.7.292、s0.7.288无 release notes 承诺仅用于开发和测试可能包含实验性功能或 bug fix不推荐用于生产从示例可以看出两种标签共用同一套三段式版本号major.minor.patch差异只在首字母前缀而不是格式不同。仓库中的脚本也按这种前缀处理版本号common/scripts/show_tag.js 会读取git describe --tags --abbrev0的结果把开头的v或s都剥掉后输出major.minor.patch形式的版本字符串。标签背后分支、CI 与发布链路两类标签不是随意打上的它们对应仓库固定的分支与发布流程分支模型README.md Branches Contributingmain是生产部署使用的默认分支版本准备好后才从staging合并进入staging用于预发布测试stable enough for testing but not yet ready for production deploymentdevelop是开发分支。团队定期把develop合并进staging做测试构建预发布部署质量满意后再合并进main并发布新版本。CI 触发条件.github/workflows/main.ymlCI 只在推送develop分支或推送匹配v*、s*的 tag 时触发构建两者都能跑通构建流程。发布校验只对v*生效在同一流水线中Verify package versions match tag 这一步仅在 ref 以refs/tags/v开头时执行即REFrefs/tags/v0.7.310 # 替换为你要发布/核对的 v* 标签 VERSION${REF#refs/tags/v} VERSION${VERSION#v} node common/scripts/bump.js --check $VERSION这一步检查所有包版本与标签一致。npm 发布流程.github/workflows/publish-npm.yml同样只在refs/tags/v*上执行bump.js --checks*标签没有对应的 npm 发布路径。也就是说v*是经过完整校验并发布 release notes的版本s*只是可构建、可测试的预发布产物——这是选型时最硬的依据。如何确认自己当前部署的是哪个版本选择版本后需要能核对实际运行的版本。仓库内可用的核对手段changelog 对照changelog.md 按## [0.7.423] - 2026-05-10这样的条目记录每个版本的功能、修复与杂项当前仓库内最新条目为0.7.423其后是0.7.413、0.7.411等。README 中给出的v*示例v0.7.310等对应的就是这条变更历史里的版本。当前源码版本仓库根目录的 common/scripts/version.txt 保存了当前工作树对应的版本号本仓库检出中为0.7.423如果你从源码构建用它与你拉取的 tag 数字部分比对即可。应用内查看changelog 条目 0.7.411 中记录了功能 (setting) Display version in Help Support button即登录 Huly 后在 Help Support 按钮处可以看到当前运行的版本用于和所选 tag 核对。按部署用途选择版本结合上述文档依据选择路径如下生产部署 / self-hosted 安装选v*。README 明确其recommended for production deployments且suitable for self-hosted installations并且随 GitHub Releases 提供 release notes便于升级前阅读变更内容。如果只关心自托管、不打算改代码或贡献开发README 的 Self-Hosting 章节指向独立的 huly-selfhost 仓库基于 docker 的便捷托管方式部署时应按该仓库说明选择其提供的版本。开发 / 测试 / 验证新功能选s*。它是为开发和测试准备的预发布构建可能包含尚未进入稳定版的实验功能或修复同时接受它不推荐用于生产这一限制。核对所选版本是否匹配包发布用上面的bump.js --check version去掉v前缀的数字部分或在 CI 中观察 Verify package versions match tag 步骤是否通过确认 tag 与包版本一致。限制与边界s*版本不要放进生产README 的原话是 Not recommended for production use。版本之间的模型结构会演进。docs/guides/backup-restore.en.md 说明当目标实例运行的平台版本比备份来源更新、恢复时遇到 model/version 错误需要给backup-restore追加--upgrade参数因此升级部署版本后要留意备份恢复的兼容性。仓库中 changelog 只记录版本内容不记录 s/v 的完整发布清单判断某个具体修复是否已包含需要对照 changelog 条目中列出的变更。按生产选v*、测试选s*、发布前用 bump 校验核对版本这条路径操作再用 changelog 或应用内版本显示完成核对就能在部署前明确自己所选的 Huly 版本处于哪个发布阶段。【免费下载链接】platformHuly — All-in-One Project Management Platform (alternative to Linear, Jira, Slack, Notion, Motion)项目地址: https://gitcode.com/GitHub_Trending/platform80/platform创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考