为 Halo 未来 JDK LTS baseline 升级做外部兼容性验证

[GG-Feng]

Prerequisites

• I have searched for related issues in the Issues list.
• This is a feature related to Halo. If it is not an issue with the project itself, it is recommended to submit it in the Discussions.
• If it is a feature suggestion for plugins and themes, please submit it in the respective plugin and theme repositories.

Your current Halo version

No response

Describe this feature

大家好，

我想分享一个我正在考虑的一个不成熟的想法：围绕 Halo 未来可能的 JDK baseline 升级，提前做一些兼容性验证工作，这样可以提前为未来可能的 JDK baseline 升级做一些兼容性验证，而不是等到baseline升级变得必要时，才集中处理迁移过程中暴露出来的问题。

我的想法不是要求官方项目去维护多套代码库，也不是要求官方创建针对不同 Java 版本的正式发布版本，更不是要替代现有测试套件。同时，我们的目标也不是维护一个以性能为目的的 fork。

从项目目前的情况来看，Halo 已经将最低 Java 版本升级到了 Java 21，并且构建、运行环境和相关依赖也已经围绕 Java 21 进行了调整。因此，我认为在当前 Java 21 baseline 之后，可以提前为后续 LTS JDK 版本做一些兼容性验证，可能会对未来维护工作有帮助。

我们的目标是为未来可能迁移到更高版本 JDK baseline 提前做兼容性验证，例如 JDK 25，或者后续其他 LTS 版本。

如果项目未来考虑把 build/source baseline 从当前 Java 21 迁移到更高版本的 JDK baseline，这项工作可以帮助更早发现一些潜在问题，包括：

• 编译或构建失败
• 单元测试或集成测试失败
• 运行时行为差异
• 第三方依赖兼容性问题
• Gradle / Spring Boot / 插件体系相关兼容性问题
• CI 和开发环境配置问题
• 用户在较新 Java 运行环境中可能遇到的问题

这类工作也可以帮助提前发现用户、贡献者或插件开发者在较新 Java 环境中可能遇到的问题，改善未来迁移时的可预期性，减少正式升级时出现意外的风险，并为后续迁移提供参考信息。

我目前的想法是，在外部维护少量面向较新 JDK baseline 的实验性兼容分支。官方项目仍然可以继续在当前主分支和当前 JDK baseline 上正常开发。我会负责同步上游代码、运行测试、记录问题，并维护这些实验性分支。

这些分支并不是要直接变成官方的独立代码库，除非未来项目和社区都认为它们确实有明确价值。现阶段，它们主要用于兼容性验证、收集社区反馈，并整理未来迁移时可能有用的参考信息。

如果确实有相关需求，我们甚至可能会在外部长期维护 2–3 个面向较新 JDK baseline 的兼容性分支，并在有帮助时把兼容性发现反馈给上游项目。对于可以独立解决的问题，我们也会尽量提交小范围、聚焦的 PR，而不是要求项目审查或维护一个大型 fork。

这个不成熟想法的目标，就是在不给官方项目增加额外维护负担的前提下，尽早发现未来 JDK baseline 升级可能带来的风险，并为后续迁移提供有用的兼容性信息。

感谢大家看到这里！

Additional information

No response

[ruibaby]

感谢你的建议和说明。

目前 Halo 的官方 Java baseline 仍然以 Java 21 为准，我们暂时没有计划维护面向未来 JDK LTS 的额外兼容性分支，也不会在当前阶段把这类外部分支纳入官方支持范围。

不过，如果你愿意在外部基于更高版本 JDK 做兼容性验证，这是欢迎的。后续如果发现具体的构建失败、测试失败、运行时差异、依赖兼容问题等，建议整理成可复现的独立 issue，或者提交小范围 PR，我们会按具体问题评估。

这个 issue 当前更像是一个长期探索方向，而不是可以直接落地的功能需求，所以我先将它关闭/转到 Discussion。