更频繁的Java长期发布

四年多以前，Mark Reinhold（甲骨文公司Java平台组的首席架构师）在他的博文 "让Java更快地前进"中说。"为了保持Java的竞争力，它必须不仅仅是继续前进--它必须更快地前进"。在那篇文章中，Reinhold建议 "在Java 9之后，我们采用一种严格的、基于时间的模式，每六个月发布一次新功能，每季度发布一次更新，每三年发布一次长期支持"。Reinhold表示，这样做的动机是，Java "必须更快地向前发展......以保持Java的竞争力。"最近，在 "让Java更快前进 "的帖子发表四年多后，Reinhold又发表了 "让Java更快前进"。

马克-莱因霍尔德在 "让Java前进得更快 "中的建议是 "每两年发布一个LTS版本"，而不是像2017年建议实施以来那样每三年发布一个长期支持（LTS）版本。Reinhold补充说："这种变化将给企业以及他们的开发人员更多的机会，让他们向前迈进"，"也将增加非LTS功能版本的吸引力。"

在 "更快推动Java发展"一文中，Reinhold解释了将LTS发布的间隔时间从三年减少到两年的动机。"开发者们对新功能感到兴奋--这很好！但许多人对LTS的发布感到沮丧。然而，许多人感到沮丧的是，他们不能立即使用这些功能，因为他们的雇主只愿意在LTS版本上部署应用程序，而LTS每三年才发布一次"。

Reinhold在OpenJDK一般讨论邮件列表中发布了类似的信息。在该消息中，他指出，"因此，JDK 17之后的LTS版本将是JDK 21（2023年），而不是JDK 23（2024年）。"Reinhold还指出，"如果接受这一改变，将不会对JDK项目中开发的主线功能版本产生影响。每一个这样的版本都是为了稳定并准备用于生产，无论它是否是LTS版本"。

Reinhold在信息的最后要求通过评论和问题来获得反馈。已经有了一些有趣的回应：

• Volker Simonis代表亚马逊Corretto团队进行了回复："我想表达我们对新的JDK LTS发布周期建议的支持。我们认为这是正确的一步，可以保持OpenJDK项目的活力和相关性，对开发者和企业都有好处。"
• Martijn Verburg代表微软Java工程团队作了答复："我们也想赞同OpenJDK构建的2年LTS建议。因为大多数终端用户生态系统更喜欢拥有LTS的额外稳定性，这是鼓励他们进行现代化努力的一个好方法！"
• Gil Tene已经代表Azul公司作了答复："我想表达我们对这个建议的强烈支持，即在OpenJDK中转向更频繁的LTS节奏。"
  • Tene补充说："这确实给整个社区带来了额外的维护负担，但在我们看来，这种负担是非常值得的。"
• RedHat的Andrew Hale回答说。"所以，对我来说，这是一个相当紧张的肯定，但是。"Hale讨论了为什么这个决定是 "微妙的"，取决于所采取的观点。
  • "作为Java的开发者以及使用者，我们也许会偏向于新功能，我们不太可能感受到升级跑步机的不利影响。"
  • "从我作为一个工程师的角度来看，转向两年的LTS周期是广泛积极的。"
  • "认证库在新的Java版本上运行可能需要几个月的努力，没有人会欢迎不得不更频繁地这样做。"
  • "我们的许多最终用户一直非常抗拒升级到新的Java版本。"
• Rémi Forax已经回答了："在这一周里，我和很多人讨论过，他们中的大多数人喜欢2年的LTS计划。2年对应用开发者来说是好的，3年对库维护者来说是更好的。至少有10倍的应用开发者"。

甲骨文Java SE支持路线图已经更新，以反映LTS发布的两年期限。它现在指出（我加了重点）："甲骨文公司将只指定某些版本为长期支持（LTS）版本。Java SE7、8、11和17是LTS版本。甲骨文公司打算每两年发布一次未来的LTS版本，这意味着下一个计划的LTS版本是2023年9月的Java 21"。

作为一个在个人项目中使用最新JDK版本（甚至经常 "玩 "OpenJDK Early-Access Builds），然后在我的 "日常工作 "中处理在不同项目中使用旧版本JDK的挫折感的开发者，我相信将LTS版本之间的等待时间从三年减少到两年将是受欢迎的。