Feast 版本管理策略全解语义化版本、分支工作流与组件成熟度标准【免费下载链接】feastThe Open Source Feature Store for AI/ML项目地址: https://gitcode.com/GitHub_Trending/fe/feast本文基于 Feast 官方的版本管理策略文档系统讲解 Feast 的语义化版本规范、master与维护分支release branch的协同工作流、组件成熟度Stable / Beta / Alpha判定标准以及不同状态下用户可获得的支持级别。读完本文你将理解 Feast 各组件处于什么状态、何时可以放心在生产环境采用以及作为贡献者应如何选择分支提交代码。一、总览Feast 采用语义化版本SemVerFeast 严格遵循 semantic versioning语义化版本规范版本号由主版本号.次版本号.修订号MAJOR.MINOR.PATCH三部分组成其语义如下主版本号MAJOR存在不兼容的 API 变更时递增次版本号MINOR向后兼容的功能性新增时递增修订号PATCH向后兼容的问题修复时递增。由于 Feast 尚未发布 1.0根据 SemVer 规范0.x 版本段仍属于活跃的初始开发期。但 Feast 对向后兼容性非常重视其 API 兼容性承诺在 docs/project/compatibility.md 中有更细化的说明当无法以向后兼容的方式修改 API 时维护者会引入新 API 并保留旧已废弃API旧 API 至少再支持 3 个次版本并在弃用早期就给出带预期移除版本的弃用警告。在仓库实现层面语义化版本被严格校验发布脚本 infra/scripts/release/bump_file_versions.py 中的is_semantic_version()会检查版本号是否恰好由三个数字段组成例如0.66.0不符合X.Y.Z形态的输入会被直接拒绝_get_semantic_version()则用正则\bv?(\d\.\d\.\d)\b从任意文件行中精确提取语义化版本。二、分支工作流master、维护分支与发布候选理解 Feast 的分支工作流是贡献者决定从哪里切分支即 PR 的 merge base 选在哪的前提。Feast 的分支体系如下分支/标签类型说明示例master主开发分支主版本与次版本发布均从此分支切出master维护分支release branch每个主/次版本对应一个长期存在的分支用于支撑该版本线的后续补丁v0.3-branch、v0.22-branch发布候选标签从维护分支上打出的预发布标签v0.3.0-rc.1稳定补丁标签从发布候选正式固化出的稳定补丁版本v0.3.0整个流程可以概括为切分支主版本Major和次版本Minor发布从master分支切出建维护分支每个主/次版本都有一个长期存在的维护分支release branch例如v0.3-branch打发布候选从维护分支上打出预发布标签release candidate例如v0.3.0-rc.1固化稳定版本发布候选验证通过后从其上打出稳定补丁版本标签例如v0.3.0。提交归属原则维护分支在目标发布内容上应基本达到feature complete功能完备。关于代码如何进入维护分支Feast 社区遵循如下约定master上的代码可以merge 或 cherry-pick到维护分支直接提交到维护分支的代码应当只适用于该发布线例如临时的 hot-fix、向后移植的安全修复、镜像哈希等并且不应再回提交到master一般情况下除非改动只针对某个特定发布流否则都应从master切出改动再通过 merge 或 cherry-pick 合并到维护分支。这一点在实际的补丁发布流程中也有体现参考 docs/project/release-process.md切补丁版本如0.22.3时维护者会先git checkout v0.22-branch然后git cherry-pick [COMMIT FROM MASTER]再git push upstream v0.22-branch将改动提交到发布分支。三、Feast 组件状态矩阵Stable / Beta / AlphaFeast 为每个组件标注了状态status用于告知用户该组件的成熟度。三种状态的官方定义如下Stable稳定组件已具备足够的稳定性和采用度Feast 社区认定其达到稳定标准具体判定标准见下节Beta测试版组件正朝着 1.0 版本演进。Beta 不代表组件不稳定只是尚未完全满足稳定性的全部标准Alpha实验版组件处于早期开发阶段或刚集成进 Feast。组件状态速览表原文档给出的组件状态矩阵如下链接已转换为仓库根目录相对路径组件状态备注Feast Python SDKStable—Feast Go Feature ServerBeta—Feast Java Feature ServerAlpha—需要说明的是组件状态会随开发进展变化。例如在 docs/roadmap.md 的 Feature Serving 一栏中Go feature server、Java feature server、Offline Feature Server、Registry server 等均标注为 Alpha说明其处于持续迭代中而 Python SDK 作为核心稳定组件其版本号可通过importlib.metadata.version(feast)获取见 sdk/python/feast/init.pySDK 安装后直接执行import feast; print(feast.__version__)即可查看当前版本见 sdk/python/feast/demos.py 中的演示代码。因此在使用任何组件前建议结合组件对应文档和版本号确认其当前状态。达到 Stable 的判定标准一个组件要被 Feast 社区认定为Stable必须满足至少来自两个组织的贡献者参与拥有完整的端到端测试套件如适用完成可扩展性与负载测试拥有自动化的发布流程Docker 镜像、PyPI 包等提供API 参考文档无破坏性变更No deprecative changes必须包含日志与监控logging and monitoring。达到 Beta 的判定标准组件达到Beta需要满足至少来自两个组织的贡献者参与拥有端到端测试套件提供 API 参考文档破坏性变更必须跨越多个次版本逐步推行并为用户提供升级路径upgrade path。状态标准的落地观察从仓库结构看自动化发布流程日志与监控等标准在工程上均有对应实现自动化发布发布由 GitHub Action 工作流驱动流程为get_dry_release_versions → validate_version_bumps → publish-web-ui-npm → release发布后触发publish工作流Python SDK 发布到 PyPI、Docker 镜像构建推送、Helm Charts 打包发布详见 docs/project/release-process.md版本号自动同步发布流程会调用 infra/scripts/release/bump_file_versions.py依据 infra/scripts/release/files_to_bump.txt 中列出的21 个文件涵盖 Helm Charts、Feast Operator 的 Makefile / kustomization / params.env、Javapom.xml、Python 多云端 requirements、UIpackage.json等批量递增版本号版本单一来源Feast Operator 的版本常量定义在 infra/feast-operator/api/feastversion/version.go文件注释明确要求Keep on line #20, this is critical to release CI保持在第 20 行这对发布 CI 至关重要说明版本行的位置被发布脚本精确依赖。四、支持级别Levels of SupportFeast 组件根据其状态提供不同级别的支持应用状态支持级别StableFeast 社区为稳定应用提供尽力而为best-effort的支持稳定组件将获得长期支持long term supportBetaFeast 社区为 Beta 应用提供尽力而为的支持Beta 应用将至少再被支持 2 个次版本Alpha支持响应因应用而异取决于该应用社区规模及其当前的活跃开发程度换言之Stable 组件有长期支持承诺Beta 组件有明确的最短支持窗口至少 2 个次版本Alpha 组件则按社区活跃度个案处理。这一支持窗口设计与兼容性文档中废弃 API 至少保留 3 个次版本的策略共同构成了 Feast 面向用户的兼容性安全网。五、来自 Feast 社区的支持尽力而为原则Feast 社区对 Stable 和 Beta 应用提供尽力而为best-effort的支持。所谓尽力而为是指不存在正式的协议或承诺保证一定解决问题但社区重视尽快处理问题的重要性。社区承诺在你满足全部以下条件时帮助诊断并解决问题问题原因落在 Feast 可控的技术框架内。例如若问题是由你所在组织的特定网络配置引起的Feast 社区可能无法提供帮助社区成员能够复现该问题问题报告者能够配合进一步的诊断与故障排查。寻求支持的渠道可参见 社区支持页面包括 Slack、GitHub Issues提交 bug 或功能请求等资源。六、实践建议作为贡献者与使用者如何定位结合上文可以给出如下可操作的定位建议作为贡献者首选从master分支切出改动提交 PR只有当改动仅适用于某个特定发布线如 hot-fix、安全补丁、镜像哈希时才直接提交到维护分支且不要回提交到master涉及发布流程时注意 infra/scripts/release/files_to_bump.txt 中列出的版本号位置约束例如version.go的第 20 行不要随意改动行号。作为使用者优先采用Stable组件如 Python SDK用于生产环境核心链路采用Beta组件如 Go Feature Server时确认其至少还会被支持 2 个次版本并留意升级路径采用Alpha组件如 Java Feature Server、各类新兴在线/离线存储插件时充分评估其开发活跃度并做好 API 可能变动的准备升级依赖前查阅 API 兼容性说明 与 Roadmap确认所依赖组件当前的状态与后续演进方向。相关文档索引API 兼容性说明废弃 API 至少支持 3 个次版本的承诺发布流程从切分支、cherry-pick 到发布 PyPI / Docker / Helm 的完整步骤社区支持寻求帮助的渠道Roadmap全部能力及其当前状态版本号批量递增脚本语义化版本校验与多文件同步的实现【免费下载链接】feastThe Open Source Feature Store for AI/ML项目地址: https://gitcode.com/GitHub_Trending/fe/feast创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
