dependabot-core 支持哪些版本、何时停止支持MAINTENANCE_STANDARDS 维护标准深度解析【免费下载链接】dependabot-core Dependabots core logic for creating update PRs.项目地址: https://gitcode.com/GitHub_Trending/de/dependabot-coreMAINTENANCE_STANDARDS.md是 dependabot-core 仓库中定义“版本支持边界”的治理文档它规定了 Dependabot 何时停止承诺支持某个包管理器或语言的旧版本、何时承诺支持新版本以及新版本弃用后的过渡期策略。本文以该文档为骨架完整还原其支持原则与弃用原则并结合 common/lib/dependabot/ecosystem.rb、各生态的package_manager.rb与 common/lib/dependabot/notices.rb 等源码说明这些纸面原则在代码中是如何被逐一落地的——读完你既能理解政策本身也能看懂政策背后“版本支持表 → 弃用警告 → 升级报错”的完整实现链路。文档定位一份“支持策略”的标准化政策MAINTENANCE_STANDARDS.md 开篇即明确其目的制定一套标准化政策用于回答两个问题——Dependabot何时停止保证对旧版本的支持以及何时开始支持新版本。文档特别强调了一个容易混淆的概念区分“Cease guaranteeing support”停止保证支持有意区别于 “deprecating support”弃用支持。某物不再被支持并不意味着会“立即把支持代码撕掉”而是更接近于“如果继续支持它变成了麻烦我们不会再去修”。文档还点明了原则存在的必要性这些原则需要结合具体情境权衡但没有原则团队就永远无法做出一致的决策。换句话说MAINTENANCE_STANDARDS 不是一张硬性时间表的对照卡而是一套决策依据——当某个上游版本 EOL、某类 lockfile 出现或消失时维护者按这里的规则推导该做哪个决定。文档由三大部分构成下文逐节展开通用支持原则General support principles弃用原则Deprecation principles新包管理器New package managers通用支持原则按 SemVer 节奏对齐上游文档指出团队尽量与 SemVer 2.0 的理念保持一致但无法保证一切场景都严格遵循。具体的支持承诺如下主版本major version一个季度内跟上对主版本的支持兼容性应在 1 个季度内建立。理由很直接主版本通常意味着破坏性更新breaking changes而用户会跟随上游迁移——Dependabot 若迟迟不支持新主版本就无法为正在迁移的用户服务。新特性如新 lockfile 类型2 到 4 个季度新功能例如一种新的 lockfile 类型应在 24 个季度内提供支持。背后的权衡是双重的留出时间让用户先迁移到新的 lockfile 类型不立刻跟进让社区先“量一量”这个新东西的采用率避免在没人用的特性上浪费工时。例外强制性的破坏性变更文档给出了一个明确的例外条款如果该变化是“破坏性”的、且强制用户必须改用新东西则应在 1 个季度内支持。括号里的注释很坦率“如果遵循 SemVer那应该是一个主版本——但 ”。也就是说现实中上游并不总是严格遵守 SemVer政策在这里按实际影响力是否强制迁移而非按版本号语义来定优先级。文档同时提醒这是一个开源项目其持续成功依赖社区的积极参与社区支持对生态的长期维护和演进至关重要。源码印证各生态如何声明“支持版本表”“1 个季度内支持新主版本”这条原则最终会体现在每个生态目录下的版本支持表中。以 bundler 生态为例bundler/lib/dependabot/bundler/package_manager.rb#L14-L27 中维护着两个核心常量# Keep versions in ascending order. # Note: Bundler 3 was intentionally skipped upstream — Bundler jumped from # 2.7 directly to 4.0 to align its major version with RubyGems, so there # is no Bundler 3.x release to support. SUPPORTED_BUNDLER_VERSIONS T.let( [Version.new(2), Version.new(4)].freeze, T::Array[Dependabot::Version] ) # Currently, we dont support any deprecated versions of Bundler # When a version is going to be unsupported, it will be added here for a while to give users time to upgrade DEPRECATED_BUNDLER_VERSIONS T.let([].freeze, T::Array[Dependabot::Version])这段代码恰好是维护标准的“活注脚”注释 “Keep versions in ascending order” 体现了团队维护版本表的纪律——支持版本必须升序排列注释里对 “Bundler 3 被上游跳号” 的解释正是前文所说“上游并不总是遵循 SemVer、需要按实际情况判断”的真实案例DEPRECATED_BUNDLER_VERSIONS旁的注释直接复述了弃用原则的操作方式一个版本即将不再支持时会先被加进这个列表一段时间给用户留出升级窗口。再看 Python 语言运行时python/lib/dependabot/python/language.rb#L18-L54 展示了“支持版本由 Docker 镜像预装决定”的机制# This list must match the versions specified at the top of python/Dockerfile # e.g. ARG PY_3_133.13.x PRE_INSTALLED_PYTHON_VERSIONS_RAW %w( 3.14.5 3.13.13 3.12.13 3.11.15 3.10.20 ).freeze # ... # The highest Python version that is no longer supported. # Python 3.9 reached end-of-life and was removed from PRE_INSTALLED_PYTHON_VERSIONS_RAW, # so a ToolVersionNotSupported error is raised for it (and any lower version). NON_SUPPORTED_HIGHEST_VERSION 3.9 DEPRECATED_VERSIONS T.let([Version.new(NON_SUPPORTED_HIGHEST_VERSION)].freeze, T::Array[Dependabot::Version])这里能看到一条完整的生命周期链条新版本先被预装进 Docker 镜像并进入支持列表旧版本如 Python 3.9上游 EOL 后从预装列表移除先落入DEPRECATED_VERSIONS作为弃用标记检测到时向用户发出警告而不是立即拒绝。这正对应文档中“停止保证支持”与“移除支持”分离的表述。弃用原则先警告再留过渡期最后才移除文档的 Deprecation principles 部分规定了上游弃用后的处理流程核心是一条时间线和两个边界条件一个版本被上游弃用后Dependabot 不保证再为它提供额外的 bugfix但通常会在上游弃用之后至少保留 3 个月的现有支持再移除移除的触发条件是保留支持开始增加维护成本、拖慢代码速度时就会把它从代码中删掉。“停止保证支持”不等于“移除支持”文档用一个 NOTE 块专门澄清了这一点“停止保证支持”有意区别于“移除支持”……即使某个版本已被弃用我们可能还会让它在代码里再留一阵子给大家更多迁移时间。我们不会再提供额外的 bugfix但如果在此期间有社区成员提交 bugfix我们大概率会合并。不过一旦保留支持开始抬高维护成本 / 拖慢代码速度我们就会移除它。这段表述划出了一个中间状态代码仍在、功能仍可用、但不再主动维护社区 PR 欢迎合并。对依赖 Dependabot 的用户而言这意味着在弃用窗口期内更新可能仍会成功但不要再指望它修 bug对贡献者而言这意味着窗口期内给旧版本补 bugfix 的 PR 是被欢迎的。弃用通告渠道Changelog 用户侧警告文档承诺弃用通知会发布在GitHub Changelog中并且尽可能地向正在使用目标弃用版本的 Dependabot 用户发送警告。理由是上游维护者都已 EOL 了某个版本Dependabot 也不该继续兜底但“只要它没有实际造成危害通常也不急着动手”。源码印证弃用警告是如何发给用户的“向用户发送警告”这条承诺在代码里有直接的对应实现。common/lib/dependabot/ecosystem.rb 定义了所有生态共用的Ecosystem::VersionManager抽象类它是整套版本支持策略的核心数据结构# common/lib/dependabot/ecosystem.rb (L109-L134 节选) def deprecated? return false unless detected_version # If the version is unsupported, the unsupported error is getting raised separately. return false if unsupported? deprecated_versions.include?(detected_version) end def unsupported? return false unless detected_version return false if supported_versions.empty? # Check if the version is not supported supported_versions.all? { |supported| supported detected_version } end两个判定函数把文档中的两个概念精确映射成了代码deprecated?检测到的版本在deprecated_versions列表中 → 对应“已弃用、进入警告过渡期”unsupported?所有supported_versions都大于检测到的版本 → 对应“彻底不受支持、直接报错”。注意deprecated?里那句return false if unsupported?的注释不受支持的情况会单独抛错处理与文档“停止保证支持 ≠ 移除支持”的分层完全一致。当版本彻底不受支持时raise_if_unsupported!会抛出明确的错误并列出可用版本# common/lib/dependabot/ecosystem.rb (L139-L152 节选) def raise_if_unsupported! return unless detected_version return unless unsupported? supported_versions_message supported_versions.map { |v| v#{v}.* }.join(, ) raise ToolVersionNotSupported.new( name, detected_version.to_s, supported_versions_message ) end对应的异常类定义在 common/lib/dependabot/errors.rb#L594Dependabot::ToolVersionNotSupported持有tool_name、detected_version、supported_versions三个字段——用户看到的错误信息会直接告诉他是哪个工具、检测到了什么版本、以及应该升级到哪些版本。而“弃用窗口期”的警告则由 common/lib/dependabot/notices.rb#L106-L141 中的generate_deprecation_notice生成def self.generate_deprecation_notice(version_manager, version_manager_type :package_manager) return nil unless version_manager.deprecated? mode NoticeMode::WARN # ... notice_type #{version_manager.name}_deprecated_warn title version_manager_type :language ? Language deprecation notice : Package manager deprecation notice description Dependabot will stop supporting #{version_manager.name} v#{version_manager.detected_version}! Notice.new( mode: mode, type: notice_type, package_manager_name: version_manager.name, title: title, description: description, show_in_pr: true, show_alert: true ) end这个实现与文档承诺逐条对应只在deprecated?为真时生成弃用窗口期专属、NoticeMode::WARN级别、描述文案直接是 “Dependabot will stop supporting …!”、并且show_in_pr: true, show_alert: true——警告会出现在更新 PR 中并触发用户侧告警这正是文档所说 “we will send warnings to users about using versions targeted for deprecation” 的落地形态。每个生态的PackageManager/Language类都继承VersionManager并传入各自的SUPPORTED_*与DEPRECATED_*版本表如 elm/lib/dependabot/elm/package_manager.rb#L17-L24所以整套弃用机制在所有生态间保持一致行为。新包管理器按“新生态”对待谨慎准入文档的最后一节 “New package managers” 指出新的包管理器需要像新生态一样对待考虑到其带来的持续维护成本在未仔细评估之前要谨慎提供支持。更多细节参见 CONTRIBUTING 的 “Contributing new ecosystems” 一节。这句话把“维护成本”这一贯穿全文的关键词落到了入口端不只是旧版本要评估去留新版本/新生态的准入同样要过成本关。结合仓库文档可以进一步看到这套“谨慎”的具体化。CONTRIBUTING.md 的 “Contributing new ecosystems” 一节指向 NEW_ECOSYSTEMS.md 这份新生态贡献指南其中与“支持边界”最直接相关的约定包括准入前必须有协调先建 issue 与 Dependabot 团队对齐实现计划、时间线、以及 release date 的获取方式cooldown 功能依赖它避免在没有维护承诺的情况下投入大量实现四个必选类是最低实现面FileFetcher、FileParser、UpdateChecker、FileUpdater继承自 common/lib/dependabot/file_fetchers 等目录下的 Base 类另可选实现MetadataFinder、Version、Requirement等——实现面的大小直接决定后续维护成本这与 MAINTENANCE_STANDARDS “按成本决定去留”的逻辑一脉相承beta 期用 feature flag 隔离新生态的文件抓取必须隐藏在allow_beta_ecosystems?特性开关之后仅在 beta 生态启用时工作GA 后才移除 beta 限制。这相当于为“新增支持”也设置了一段可撤销的观察期基础设施由自动化统一维护rake ecosystem:create[...]一条命令即可生成脚手架并更新 CI 工作流、issue 标签、omnibus/lib/dependabot/omnibus.rb 等支撑文件任务幂等、可跳过已配置项。从源码结构看MAINTENANCE_STANDARDS 中“新版本 1 个季度内支持、新特性 24 个季度”的节奏与 NEW_ECOSYSTEMS 中 “beta 期 48 周社区验证 GA 前 24 周收尾” 的时间预期是可以互相衔接的先以 beta flag 控制风险敞口验证达标后再转正转正时该生态的SUPPORTED_*_VERSIONS版本表也随之开始长期维护。对维护者与用户的实操启示把政策与代码对照起来可以得到几条可直接操作的结论。对生态维护者往仓库里加/删支持版本改动点就是两个常量数组。以 bundler/lib/dependabot/bundler/package_manager.rb 为模板新主版本可用后把新版本加进SUPPORTED_*_VERSIONS保持升序版本将 EOL 时先把它从SUPPORTED移入DEPRECATED_*_VERSIONS让deprecated?开始向用户发警告保留至少 3 个月确认维护成本过高后再从代码中彻底移除。语言运行时版本要同步镜像。如 python/lib/dependabot/python/language.rb#L15-L17 注释要求预装版本列表“必须与python/Dockerfile顶部的版本声明一致”如ARG PY_3_133.13.x。政策层面承诺支持某版本前提是运行环境里真的装了这个版本。配套动作在 Changelog 发布弃用通告文档承诺并保持DEPRECATED列表中的版本确实仍能工作一段时间——generate_deprecation_notice只负责“告知”不负责“兜底”兜底来自代码仍被保留这一事实本身。对使用 Dependabot 的用户区分两类信号PR 中出现 “Package manager deprecation notice”WARN意味着你用的版本进入弃用过渡期——更新仍会进行、但不再有额外 bugfix应规划升级而ToolVersionNotSupported错误则意味着版本已完全不受支持错误信息里会给出应升级到的版本列表如v2.*, v4.*此时必须升级工具版本才能继续获得更新。理解“不再支持 ≠ 更新立即失败”在弃用窗口内Dependabot 可能仍会为旧版本产生更新甚至合并社区 bugfix所以过渡期内的警告要当作“最后通牒”而非“已经坏掉”来处理。关注版本跳号的例外情况如 bundler 直接从 2.7 跳到 4.0无 3.x说明“支持版本表”按上游实际发布为准而非 SemVer 推演——排查版本问题时以各生态SUPPORTED_*常量为准而不是自己推算。小结MAINTENANCE_STANDARDS.md 用简短的篇幅确立了 dependabot-core 的版本治理骨架按 SemVer 节奏承诺支持新主版本1 个季度与新特性24 个季度强制迁移除外上游弃用后不再提供额外 bugfix、但保留至少 3 个月过渡期期间欢迎社区修复成本过高时移除弃用经 Changelog 公示并尽量向用户发警告新包管理器按新生态流程谨慎准入。而仓库源码给出了这套政策的完整实现证据Ecosystem::VersionManager的deprecated?/unsupported?/raise_if_unsupported!三层判定common/lib/dependabot/ecosystem.rb#L109-L152、各生态升序维护的SUPPORTED_*/DEPRECATED_*版本表、ToolVersionNotSupported错误common/lib/dependabot/errors.rb#L594、以及 WARN 级弃用通告generate_deprecation_noticecommon/lib/dependabot/notices.rb#L106-L141——政策、数据结构与用户可见行为三者一一对应这正是该文档作为“维护标准”能够长期指导团队做出一致决策的原因。【免费下载链接】dependabot-core Dependabots core logic for creating update PRs.项目地址: https://gitcode.com/GitHub_Trending/de/dependabot-core创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考