Langflow 发布工程指南RC 分支流程、回归日志审查、标签校验与 LFX 兼容性契约【免费下载链接】langflowLangflow is a powerful tool for building and deploying AI-powered agents and workflows.项目地址: https://gitcode.com/GitHub_Trending/la/langflow本文以 Langflow 仓库根目录的 RELEASE.md 为主体系统讲解 Langflow 的release-when-ready发布节奏从 RCrelease candidate分支的切分与合并策略到回归日志regression log的审查、v前缀标签的 CI 校验再到 LFX 与 Langflow 共享 major.minor 版本线的兼容性契约。读完本篇你可以完整复现 Langflow 一次正式发布的全部手工步骤并理解每个产物PyPI 包、Docker 镜像、LFX 执行器的版本对齐机制。发布节奏与目标Langflow 采用release-when-ready的节奏每个发布周期通常持续 4–6 周具体时长取决于 QA 与稳定化需求。RELEASE.md 明确了五个核心目标让main分支保持高速迭代同时在功能成熟时产出稳定的发布构建为 QA 与最后时刻的修复提供一个隔离分支即 RC 分支尽可能保持线性、可读的提交历史确保发布代码在公开前经过充分测试最小化关键缺陷的修复时间。发布流程总览OSS QA → Desktop QA → Release整个发布周期分为四个阶段其中两个 QA 阶段各持续约一周main分支在此期间始终不中断新功能开发。1. OSS QA创建包含langflow及相关 PyPI 包如lfx的 OSS RC 分支。期间QA 以手工方式执行缺陷修复合并进 RC 分支新功能继续在main上开发。2. Desktop QAOSS QA 与修复完成后基于最终的 OSS RC 创建 Desktop RC 分支执行同样的手工 QA、修复合并进 Desktop RC、新功能留在main的流程。3. ReleaseOSS 与 Desktop 两侧 QA 完成后分别从各自的 RC 分支切出最终发布发布时间与 Langflow DevRel 团队协调发布后至少 24 小时需监控 Discord、GitHub 等支持渠道的关键缺陷报告。4. 发布产物发布工作流自动产出以下两类产物PyPI 包包名说明langflow主包含全部集成langflow-base不含集成的核心框架lfx轻量级执行器 CLIlangflow-sdk编程式访问 SDK更新时发布Docker 镜像镜像说明langflowai/langflow完整 Langflow 镜像langflowai/langflow-backend仅后端独立发布langflowai/langflow-frontend仅前端独立发布langflowai/langflow-ep企业版镜像独立发布langflowai/langflow-base不含集成的基础镜像注意backend、frontend 与 enterprise 镜像独立于主镜像发布——即使主版本在 Docker Hub 上已存在它们仍会被构建。分支模型与合并策略RELEASE.md 定义了双分支模型分支用途合并策略main集成分支所有功能 PR 默认指向它Squash Merge线性历史release-X.Y.Z如release-1.4.3临时 RC 分支仅发布周期内活跃接受带type:release标签的 QA 与阻塞缺陷 PR分支内Squash Merge最终合并前 rebase 到main合并策略有三条纪律全局使用Squash Merge保证原子提交与干净历史RC 开放期间定期与 main 再同步尽早暴露冲突同时保持线性历史git checkout release-X.Y.Z git fetch origin git rebase origin/main回合并merge-back必须是 fast-forward only若无法快进须先把 RC rebase 到main再合并。对应 FAQ 中的两个高频问题RC 与 main 之间永远不 merge、只 rebase分支删除目前尚未自动化回合并与清理均为手工操作。发布操作步骤可直接照做1. 切出 RC 分支git checkout main git pull # 确保本地 main 最新 git checkout -b release-X.Y.Z # 创建 RC 分支 git push -u origin release-X.Y.Z # 推送到远端2. 向 RC 应用缺陷修复按常规创建功能分支发起指向release-X.Y.Z的 PR正常评审与批准评审后合并进 RC 分支。3. 审查回归日志打标签前审查regressions/X.Y.x.yaml确认不存在未解决的blocking条目若存在须获得签署sign-off。4. 最终发布git checkout release-X.Y.Z git pull # 确保 RC 分支最新 git tag vX.Y.Z # 创建最终发布标签 git push origin vX.Y.Z # 推送标签5. 将 RC 合并回 maingit checkout main git merge --ff-only release-X.Y.Z # 快进 main纳入 RC 上的所有修复回归日志Regression Log发布流程中最容易被忽略、但仓库中有着完整落地实现的一环是回归日志。regressions/README.md 定义了它每个发布周期对应一个 YAML 文件记录在旧版本正常、新版本损坏的行为作为发布前后已知问题的唯一事实来源。回归的发现渠道包括手工 QA、自动化测试、支持工单与代码评审。条目写入步骤打开回归首次出现版本的regressions/version.yaml例如首次出现在 1.9.0 就打开1.9.x.yaml不存在则创建按 schema 在entries:下新增条目若严重度与规避方案尚未确认设status: triage发起指向当前活跃 RC 分支的 PR修复 PR 与 YAML 条目可以指向不同分支。条目 schema{ id: GH-12345, title: Short plain-language description, status: triage, area: flow_editor, first_bad_version: 1.10.0, last_known_good_version: 1.9.0, resolved_in_version: 1.10.1, fix_pr: https://github.com/langflow-ai/langflow/pull/12345, workaround: none }其中resolved_in_version与fix_pr是可选字段首次登记时可省略修复落地后再补上。状态取值Status含义triage已发现、尚未完全评估首次登记的默认值ship_with_note带问题发布文档必须传达 workaroundresolved已修复须补resolved_in_version记录修复版本blocking发布阻塞项发布前须显式签署area 取值覆盖flow_editor可视化构建器 UI、components核心组件、mcpMCP 服务注册与侧边栏、apiREST 端点、lfxCLI 执行器、auth登录/API key/用户管理、database迁移与存储、integrations第三方组件、starter_projects内置示例流。仓库中的真实文件可以印证这套流程regressions/1.10.x.yaml 首条目GH-13538记录了Python Code Structured 工具先禁用后移除未认证 RCE 修复状态为ship_with_note、area 为components、first_bad_version: 1.10.0并给出 workaround——用 Python InterpreterPythonREPLComponent组件重建该步骤。此外还有 regressions/1.9.x.yaml 与 regressions/1.11.x.yaml对应不同发布周期。发布前的审查分工QA 与支持工程师在 RC 期间持续把条目移出triage、补充 workaround、将已修复项标记为resolved并填上resolved_in_version文档团队在发布前审查所有ship_with_note条目将 workaround 文案写入发布说明Release Captain 最终确认没有未解决的blocking条目如有则须由维护者在 GitHub issue 中签署。版本管理与标签规则遵循语义化版本Semantic VersioningMAJOR.MINOR.PATCHRC 标签使用-rc.N后缀例如v1.8.0-rc.1所有标签必须以v前缀开头如v1.9.1而非1.9.1。最后一条规则不只是命名偏好而是有 CI 硬校验的发布工作流 release.yml 中的validate-tag-format步骤用正则^v[0-9]\.[0-9]\.[0-9]$校验标签格式不符合则直接失败随后还会检查是否存在不带v前缀的同名重复标签——若1.8.3与v1.8.3同时存在GitHub 的 release notes 生成会选错 base 比较导致 changelog 不完整。工作流检测到重复标签时会打印指向错误 commit 的诊断信息并提示用git push origin :refs/tags/tag删除。该工作流还支持dry_run默认开启禁用对 PyPI、Docker、GitHub Release 的一切推送以及按包/镜像维度的独立开关release_package_base、release_package_main、release_lfx、release_sdk、release_bundles、build_docker_base、build_docker_main与backend/frontend/enterprise 镜像独立发布的说明一致。LFX 兼容性契约Langflow 与 LFX 共享同一条major.minor 版本线兼容性契约为LFX X.Y.N 保证兼容任何由 Langflow X.Y.M 导出的 Flow。补丁版本N与M相互独立——LFX 的补丁不要求 Langflow 同步发补丁反之亦然。这一对齐在仓库中是可见的src/lfx/pyproject.toml 当前version 1.12.0与 pyproject.toml 中langflow的1.12.0及 src/frontend/package.json 前端版本1.12.0完全一致印证了 LFX 与宿主共享版本线的事实而 src/sdk/pyproject.toml 的langflow-sdk为独立的0.4.0线与 RELEASE.md 中SDK 更新时才发布的描述吻合。版本管理make patchmake patch vX.Y.Z会同时更新四个产物的版本。RELEASE.md 给出的版本表为产物设定版本langflowX.Y.Zlangflow-base0.Y.ZlfxX.Y.ZfrontendX.Y.Z结合 Makefile 中patch目标的实现可以看出其具体动作该目标先由X.Y.Z派生出兼容性下限LANGFLOW_COMPAT_VERSION即X.Y.0然后依次改写主pyproject.toml并把langflow-base依赖约束更新为~X.Y.0、src/backend/base/pyproject.toml、src/lfx/pyproject.toml、src/sdk/pyproject.toml同时更新component_index.json中的版本。从当前仓库的实际状态看langflow-base已升至与langflow相同的1.12.0src/backend/base/pyproject.toml即 base 包已跟随主版本线对齐文档表格中0.Y.Z的历史约定可视为该对齐完成前的形态。切一个 LFX 补丁发布scripts/release-lfx.shscripts/release-lfx.sh 封装了 LFX 补丁发布的完整准备流程用法为scripts/release-lfx.sh version并支持--dry-run只校验不落地。脚本的关键行为前置检查必须在仓库根目录运行依赖src/lfx/pyproject.toml存在非 dry-run 模式下检测到未提交改动会直接退出版本格式校验用正则^[0-9]\.[0-9]\.[0-9](-[a-zA-Z0-9])?$强制语义化格式minor 对齐软校验提取 LFX 新版本的major.minor与主pyproject.toml中 Langflow 的 minor 比较不一致时打印告警LFX minor version ... does not match Langflow minor version但不阻断——同一 minor 内的补丁发布是预期且合理的版本写入更新src/lfx/pyproject.toml的version以及src/lfx/docker/Dockerfile*中的ARG LFX_VERSION发布前验证在src/lfx下跑make test失败即回滚改动并退出随后uv build验证打包成功后清理dist/提交与打标签生成提交chore(lfx): bump version to version并创建附注标签lfx-vversion注意 LFX 标签带lfx-前缀与主发布的vX.Y.Z区分收尾指引提示推送 commit 与标签后在 CI 中手动运行 LFX Release 工作流按提示选择发布 PyPI、构建 Docker 镜像standard 与 alpine、创建 GitHub Release。对用户的含义pinlfx~X.Y.0用户可以lfx~X.Y.0的方式在requirements.txt中固定从而只接收对应 Langflow minor 下所有兼容的 LFX 补丁发布而不跨 minor 线。一个必须向用户明示的历史事件是lfx 0.5.x 到 1.10.0 的版本跳变LFX 从独立的0.5.x线重新对齐到 Langflow 的 major.minor 线版本号一步从0.5.0跳到1.10.0——这是编号规则变更而非 95 个 minor 的功能积压。该跳变会影响下游 pin且 pip 与 uv 都不会主动提示因此必须在发布公告中声明而不仅仅写在 RELEASE.mdlfx0.5.x或lfx1.0的 pin不会升级有意为之那些部署原地保持lfx0.5,1的 pin不会升级lfx0.5无上界的 pin会在下次安装时拉到1.10.0——一次无警告的 major 跳跃。因此 RELEASE.md 的建议是此后一律使用lfx~X.Y.0例如lfx~1.10.0这类兼容区间 pin跟踪某个 Langflow minor 下的兼容补丁而不静默跨越 minor 线。角色分工与 FAQ角色职责Release Captain每周期轮换拥有时间线、分支切分、打标签、回合并PR Author确保测试通过若缺陷需要进 RC为 PR 标记type:releaseCI在测试失败或缺少标签时阻断合并FAQ 摘要是否会把 main 合并进 RC不会。始终把 RC rebase 到main以保留线性历史。能否自动化分支删除目前不能——回合并与清理仍是手工操作。时间线有多灵活非常灵活。QA 与稳定化阶段可按质量需要延长。小结Langflow 的发布体系可以归纳为三条主线其一流程主线——main快速迭代、RC 分支隔离 QA、rebase 保持线性、fast-forward 回合并配套回归日志 YAML 作为已知问题的唯一事实来源其二产物主线——PyPI 四包langflow、langflow-base、lfx、langflow-sdk与五个 Docker 镜像按开关独立发布make patch统一抬升版本scripts/release-lfx.sh单独支撑 LFX 补丁线其三契约主线——LFX 与 Langflow 共享 major.minor 版本线v前缀标签由 CI 强制校验用户侧以lfx~X.Y.0锁定兼容区间。仓库中的 regressions/、Makefile、.github/workflows/release.yml 与 scripts/release-lfx.sh 为上述每个环节都提供了可直接核对的实现证据读者可沿这些文件进一步深入发布工程细节。【免费下载链接】langflowLangflow is a powerful tool for building and deploying AI-powered agents and workflows.项目地址: https://gitcode.com/GitHub_Trending/la/langflow创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Langflow 发布工程指南：RC 分支流程、回归日志审查、标签校验与 LFX 兼容性契约
Langflow 发布工程指南RC 分支流程、回归日志审查、标签校验与 LFX 兼容性契约【免费下载链接】langflowLangflow is a powerful tool for building and deploying AI-powered agents and workflows.项目地址: https://gitcode.com/GitHub_Trending/la/langflow本文以 Langflow 仓库根目录的 RELEASE.md 为主体系统讲解 Langflow 的release-when-ready发布节奏从 RCrelease candidate分支的切分与合并策略到回归日志regression log的审查、v前缀标签的 CI 校验再到 LFX 与 Langflow 共享 major.minor 版本线的兼容性契约。读完本篇你可以完整复现 Langflow 一次正式发布的全部手工步骤并理解每个产物PyPI 包、Docker 镜像、LFX 执行器的版本对齐机制。发布节奏与目标Langflow 采用release-when-ready的节奏每个发布周期通常持续 4–6 周具体时长取决于 QA 与稳定化需求。RELEASE.md 明确了五个核心目标让main分支保持高速迭代同时在功能成熟时产出稳定的发布构建为 QA 与最后时刻的修复提供一个隔离分支即 RC 分支尽可能保持线性、可读的提交历史确保发布代码在公开前经过充分测试最小化关键缺陷的修复时间。发布流程总览OSS QA → Desktop QA → Release整个发布周期分为四个阶段其中两个 QA 阶段各持续约一周main分支在此期间始终不中断新功能开发。1. OSS QA创建包含langflow及相关 PyPI 包如lfx的 OSS RC 分支。期间QA 以手工方式执行缺陷修复合并进 RC 分支新功能继续在main上开发。2. Desktop QAOSS QA 与修复完成后基于最终的 OSS RC 创建 Desktop RC 分支执行同样的手工 QA、修复合并进 Desktop RC、新功能留在main的流程。3. ReleaseOSS 与 Desktop 两侧 QA 完成后分别从各自的 RC 分支切出最终发布发布时间与 Langflow DevRel 团队协调发布后至少 24 小时需监控 Discord、GitHub 等支持渠道的关键缺陷报告。4. 发布产物发布工作流自动产出以下两类产物PyPI 包包名说明langflow主包含全部集成langflow-base不含集成的核心框架lfx轻量级执行器 CLIlangflow-sdk编程式访问 SDK更新时发布Docker 镜像镜像说明langflowai/langflow完整 Langflow 镜像langflowai/langflow-backend仅后端独立发布langflowai/langflow-frontend仅前端独立发布langflowai/langflow-ep企业版镜像独立发布langflowai/langflow-base不含集成的基础镜像注意backend、frontend 与 enterprise 镜像独立于主镜像发布——即使主版本在 Docker Hub 上已存在它们仍会被构建。分支模型与合并策略RELEASE.md 定义了双分支模型分支用途合并策略main集成分支所有功能 PR 默认指向它Squash Merge线性历史release-X.Y.Z如release-1.4.3临时 RC 分支仅发布周期内活跃接受带type:release标签的 QA 与阻塞缺陷 PR分支内Squash Merge最终合并前 rebase 到main合并策略有三条纪律全局使用Squash Merge保证原子提交与干净历史RC 开放期间定期与 main 再同步尽早暴露冲突同时保持线性历史git checkout release-X.Y.Z git fetch origin git rebase origin/main回合并merge-back必须是 fast-forward only若无法快进须先把 RC rebase 到main再合并。对应 FAQ 中的两个高频问题RC 与 main 之间永远不 merge、只 rebase分支删除目前尚未自动化回合并与清理均为手工操作。发布操作步骤可直接照做1. 切出 RC 分支git checkout main git pull # 确保本地 main 最新 git checkout -b release-X.Y.Z # 创建 RC 分支 git push -u origin release-X.Y.Z # 推送到远端2. 向 RC 应用缺陷修复按常规创建功能分支发起指向release-X.Y.Z的 PR正常评审与批准评审后合并进 RC 分支。3. 审查回归日志打标签前审查regressions/X.Y.x.yaml确认不存在未解决的blocking条目若存在须获得签署sign-off。4. 最终发布git checkout release-X.Y.Z git pull # 确保 RC 分支最新 git tag vX.Y.Z # 创建最终发布标签 git push origin vX.Y.Z # 推送标签5. 将 RC 合并回 maingit checkout main git merge --ff-only release-X.Y.Z # 快进 main纳入 RC 上的所有修复回归日志Regression Log发布流程中最容易被忽略、但仓库中有着完整落地实现的一环是回归日志。regressions/README.md 定义了它每个发布周期对应一个 YAML 文件记录在旧版本正常、新版本损坏的行为作为发布前后已知问题的唯一事实来源。回归的发现渠道包括手工 QA、自动化测试、支持工单与代码评审。条目写入步骤打开回归首次出现版本的regressions/version.yaml例如首次出现在 1.9.0 就打开1.9.x.yaml不存在则创建按 schema 在entries:下新增条目若严重度与规避方案尚未确认设status: triage发起指向当前活跃 RC 分支的 PR修复 PR 与 YAML 条目可以指向不同分支。条目 schema{ id: GH-12345, title: Short plain-language description, status: triage, area: flow_editor, first_bad_version: 1.10.0, last_known_good_version: 1.9.0, resolved_in_version: 1.10.1, fix_pr: https://github.com/langflow-ai/langflow/pull/12345, workaround: none }其中resolved_in_version与fix_pr是可选字段首次登记时可省略修复落地后再补上。状态取值Status含义triage已发现、尚未完全评估首次登记的默认值ship_with_note带问题发布文档必须传达 workaroundresolved已修复须补resolved_in_version记录修复版本blocking发布阻塞项发布前须显式签署area 取值覆盖flow_editor可视化构建器 UI、components核心组件、mcpMCP 服务注册与侧边栏、apiREST 端点、lfxCLI 执行器、auth登录/API key/用户管理、database迁移与存储、integrations第三方组件、starter_projects内置示例流。仓库中的真实文件可以印证这套流程regressions/1.10.x.yaml 首条目GH-13538记录了Python Code Structured 工具先禁用后移除未认证 RCE 修复状态为ship_with_note、area 为components、first_bad_version: 1.10.0并给出 workaround——用 Python InterpreterPythonREPLComponent组件重建该步骤。此外还有 regressions/1.9.x.yaml 与 regressions/1.11.x.yaml对应不同发布周期。发布前的审查分工QA 与支持工程师在 RC 期间持续把条目移出triage、补充 workaround、将已修复项标记为resolved并填上resolved_in_version文档团队在发布前审查所有ship_with_note条目将 workaround 文案写入发布说明Release Captain 最终确认没有未解决的blocking条目如有则须由维护者在 GitHub issue 中签署。版本管理与标签规则遵循语义化版本Semantic VersioningMAJOR.MINOR.PATCHRC 标签使用-rc.N后缀例如v1.8.0-rc.1所有标签必须以v前缀开头如v1.9.1而非1.9.1。最后一条规则不只是命名偏好而是有 CI 硬校验的发布工作流 release.yml 中的validate-tag-format步骤用正则^v[0-9]\.[0-9]\.[0-9]$校验标签格式不符合则直接失败随后还会检查是否存在不带v前缀的同名重复标签——若1.8.3与v1.8.3同时存在GitHub 的 release notes 生成会选错 base 比较导致 changelog 不完整。工作流检测到重复标签时会打印指向错误 commit 的诊断信息并提示用git push origin :refs/tags/tag删除。该工作流还支持dry_run默认开启禁用对 PyPI、Docker、GitHub Release 的一切推送以及按包/镜像维度的独立开关release_package_base、release_package_main、release_lfx、release_sdk、release_bundles、build_docker_base、build_docker_main与backend/frontend/enterprise 镜像独立发布的说明一致。LFX 兼容性契约Langflow 与 LFX 共享同一条major.minor 版本线兼容性契约为LFX X.Y.N 保证兼容任何由 Langflow X.Y.M 导出的 Flow。补丁版本N与M相互独立——LFX 的补丁不要求 Langflow 同步发补丁反之亦然。这一对齐在仓库中是可见的src/lfx/pyproject.toml 当前version 1.12.0与 pyproject.toml 中langflow的1.12.0及 src/frontend/package.json 前端版本1.12.0完全一致印证了 LFX 与宿主共享版本线的事实而 src/sdk/pyproject.toml 的langflow-sdk为独立的0.4.0线与 RELEASE.md 中SDK 更新时才发布的描述吻合。版本管理make patchmake patch vX.Y.Z会同时更新四个产物的版本。RELEASE.md 给出的版本表为产物设定版本langflowX.Y.Zlangflow-base0.Y.ZlfxX.Y.ZfrontendX.Y.Z结合 Makefile 中patch目标的实现可以看出其具体动作该目标先由X.Y.Z派生出兼容性下限LANGFLOW_COMPAT_VERSION即X.Y.0然后依次改写主pyproject.toml并把langflow-base依赖约束更新为~X.Y.0、src/backend/base/pyproject.toml、src/lfx/pyproject.toml、src/sdk/pyproject.toml同时更新component_index.json中的版本。从当前仓库的实际状态看langflow-base已升至与langflow相同的1.12.0src/backend/base/pyproject.toml即 base 包已跟随主版本线对齐文档表格中0.Y.Z的历史约定可视为该对齐完成前的形态。切一个 LFX 补丁发布scripts/release-lfx.shscripts/release-lfx.sh 封装了 LFX 补丁发布的完整准备流程用法为scripts/release-lfx.sh version并支持--dry-run只校验不落地。脚本的关键行为前置检查必须在仓库根目录运行依赖src/lfx/pyproject.toml存在非 dry-run 模式下检测到未提交改动会直接退出版本格式校验用正则^[0-9]\.[0-9]\.[0-9](-[a-zA-Z0-9])?$强制语义化格式minor 对齐软校验提取 LFX 新版本的major.minor与主pyproject.toml中 Langflow 的 minor 比较不一致时打印告警LFX minor version ... does not match Langflow minor version但不阻断——同一 minor 内的补丁发布是预期且合理的版本写入更新src/lfx/pyproject.toml的version以及src/lfx/docker/Dockerfile*中的ARG LFX_VERSION发布前验证在src/lfx下跑make test失败即回滚改动并退出随后uv build验证打包成功后清理dist/提交与打标签生成提交chore(lfx): bump version to version并创建附注标签lfx-vversion注意 LFX 标签带lfx-前缀与主发布的vX.Y.Z区分收尾指引提示推送 commit 与标签后在 CI 中手动运行 LFX Release 工作流按提示选择发布 PyPI、构建 Docker 镜像standard 与 alpine、创建 GitHub Release。对用户的含义pinlfx~X.Y.0用户可以lfx~X.Y.0的方式在requirements.txt中固定从而只接收对应 Langflow minor 下所有兼容的 LFX 补丁发布而不跨 minor 线。一个必须向用户明示的历史事件是lfx 0.5.x 到 1.10.0 的版本跳变LFX 从独立的0.5.x线重新对齐到 Langflow 的 major.minor 线版本号一步从0.5.0跳到1.10.0——这是编号规则变更而非 95 个 minor 的功能积压。该跳变会影响下游 pin且 pip 与 uv 都不会主动提示因此必须在发布公告中声明而不仅仅写在 RELEASE.mdlfx0.5.x或lfx1.0的 pin不会升级有意为之那些部署原地保持lfx0.5,1的 pin不会升级lfx0.5无上界的 pin会在下次安装时拉到1.10.0——一次无警告的 major 跳跃。因此 RELEASE.md 的建议是此后一律使用lfx~X.Y.0例如lfx~1.10.0这类兼容区间 pin跟踪某个 Langflow minor 下的兼容补丁而不静默跨越 minor 线。角色分工与 FAQ角色职责Release Captain每周期轮换拥有时间线、分支切分、打标签、回合并PR Author确保测试通过若缺陷需要进 RC为 PR 标记type:releaseCI在测试失败或缺少标签时阻断合并FAQ 摘要是否会把 main 合并进 RC不会。始终把 RC rebase 到main以保留线性历史。能否自动化分支删除目前不能——回合并与清理仍是手工操作。时间线有多灵活非常灵活。QA 与稳定化阶段可按质量需要延长。小结Langflow 的发布体系可以归纳为三条主线其一流程主线——main快速迭代、RC 分支隔离 QA、rebase 保持线性、fast-forward 回合并配套回归日志 YAML 作为已知问题的唯一事实来源其二产物主线——PyPI 四包langflow、langflow-base、lfx、langflow-sdk与五个 Docker 镜像按开关独立发布make patch统一抬升版本scripts/release-lfx.sh单独支撑 LFX 补丁线其三契约主线——LFX 与 Langflow 共享 major.minor 版本线v前缀标签由 CI 强制校验用户侧以lfx~X.Y.0锁定兼容区间。仓库中的 regressions/、Makefile、.github/workflows/release.yml 与 scripts/release-lfx.sh 为上述每个环节都提供了可直接核对的实现证据读者可沿这些文件进一步深入发布工程细节。【免费下载链接】langflowLangflow is a powerful tool for building and deploying AI-powered agents and workflows.项目地址: https://gitcode.com/GitHub_Trending/la/langflow创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考