GoCD 在即将发布的 JDK 版本上的早期验证

大家好，我想分享我们目前正在考虑的一个想法：对 GoCD 与未来 JDK 版本的兼容性进行一些外部验证和跟踪工作。这个想法并不是要求官方项目立即提高其最低 Java 基线，也不是为了维护多个代码基，为不同的 Java 版本创建单独的官方版本，或替换现有的测试套件。同样，我们的目标不是维护一个专注于性能的分支。从当前项目的设置来看，GoCD 已经在其构建、测试和发布流程中采用了 Java 25 LTS，同时仍然将 Java 17 作为支持的最低版本，适用于自带 JRE 的环境。这表明项目积极地跟踪新的 Java LTS 版本，同时也重视现有用户运行时环境的兼容性。然而，JDK 版本将在未来几年继续演进。尽管 GoCD 目前支持和使用 Java 25 LTS，但未来的 JDK 升级可能会引入依赖更新、运行时行为变化、构建工具链调整或跨平台包装差异。因此，我们认为对未来 JDK 版本进行早期兼容性验证可能会有助于持续维护。我们的目标是对 GoCD 与 Java 25 以外的 JDK 版本进行外部验证，包括未来的 JDK 版本，如 JDK 26、JDK 27 或更高版本的 LTS 基线。这种验证可以帮助更早地识别潜在问题，例如： * 编译或构建失败 * 单元或集成测试失败 * 运行时行为差异 * Gradle / JRuby / server-agent 通信兼容性问题 * 第三方依赖在新版 JDK 上的兼容性问题 * Windows、macOS 和 Linux 之间的运行时或包装差异 * CI 和开发环境配置问题 * 用户在运行 GoCD 在新版 Java 环境时可能遇到的问题 我们目前的计划是为新版 JDK 维护一小部分外部实验性兼容性分支或测试环境。官方项目可以继续在当前主分支上进行正常开发，使用当前的最低 Java 基线、当前的发布 JDK 版本和现有的发布周期。我们将负责同步上游代码、运行相关测试、记录问题并维护这些实验性验证工作。这些分支或测试环境的目的是进行兼容性验证、收集反馈并准备可能对未来迁移或适应新版 JDK 有用的参考信息。如果有真正的需求，我们可能会长期维护两到三个外部兼容性验证分支或测试配置，并向上游报告有用的发现或小型、专注的 PR。对于可以独立解决的问题，我们将记录…