Lua 社区需要学会向前看

# Lua 社区需要学会向前看 - hisham.hm 来源：https://hisham.hm/2026/08/04/the-lua-community-needs-to-learn-to-move-on 这篇文章本可以写得很长，但我会尽量写短一些，基本上就是展开我刚在 GitHub 评论里说的话。 最近，Mike Pall 从他的上游 GitHub 仓库中删除了一些旧版 LuaJIT 的标签。这是一种相当极端的强制升级手段，在正常情况下，这会被视为一种非常……呃，不友好的举动，任何 FOSS 项目里都是如此。 但我能理解他可能的挫败感。我知道有大量项目长期停留在 `luajit-2.1.0-beta3` 这样的标签上。他很可能是收到了针对十多年前就已修复的 bug 的报告。我知道这一点，因为 LuaRocks 世界也是如此：我们一直收到针对 2012 年 LuaRocks 2.0.8 的 bug 报告，因为各发行版没有更新它们。我也曾经站在另一边 (https://gobolinux.org/)，知道发行版维护者有多辛苦，所以我并不是在指责谁。我只是想说，维护以及让人们更新是非常困难的。 然而，这在 Lua 社区是一个特别棘手的问题。 自从 Lua/LuaJIT 在 5.2 时代分裂以来（天哪，那已经是……15 年前了吧？！），社区就陷入了一种瘫痪性的倾向：永远支持旧版本，即使上游早已不再支持它们。制作 Lua 库的人们不断测试他们的包，要兼容 Lua 5.1、5.2、5.3、5.4，现在还有 5.5；然后是 LuaJIT 2.1，有时还有 OpenResty 变体，现在又有了 3.0。 我理解 Lua 是一种可嵌入的语言，如果在某个时间点你决定在应用中捆绑 Lua 5.2，并围绕它构建插件生态系统，那么你就得永远和它绑定在一起。但那是你的应用生态需要去维护的事情。 对于作为一种可扩展语言的 Lua（即解释器 + 库），情况应该有所不同，它应该更像其他任何一种动态/脚本语言。我们真的应该（逐渐地？）转向只支持最新的 PUC-Rio Lua 和最新的 LuaJIT，最多也就这样了。 我知道我们为什么会走到今天这一步。我了解这段历史，因为我亲身经历过：在 Lua/LuaJIT 分裂之时，人们想同时支持两种环境，而以 5.1 为目标是一种很好的方式。接着 5.2、5.3 等版本相继出现，人们想继续支持最新的 PUC-Rio Lua，但仍然觉得被 5.1 这个锚点束缚着。我确信这其中有我的一部分责任，因为我参与了这件事并帮助了其他人，我维护了 compat-5.3——它本身是 compat-5.2 的演进，其历史可以一直追溯到 compat-5.0，那早在我参与 Lua 之前就已存在……而那就是 20 多年前的事了。 如今，我为试图扭转这一局面所做的微小贡献是 Teal (https://teal-language.org/)，一门旨在成为 Lua 界的 TypeScript 的语言：它不仅旨在为语言带来类型系统，还旨在弥合版本差距。你可以用 Teal 写一次代码，然后通过 `--gen-target=5.1` 一直到 `--gen-target=5.5` 生成 Lua。希望这能帮助 Lua 代码作者摆脱 Lua 5.1 这个锚点的束缚。 但即使你不用 Teal，如果你是 Lua 库作者，也可以考虑效仿 Roberto 和 Mike 的做法：他们确实会让自己的语言版本停止支持（EOL）。LuaJIT 1.0 已 EOL，LuaJIT 2.0.0 已 EOL（有一个 2.0 bugfix 分支 (https://luajit.org/status.html)，但旧 tarball 已 EOL (https://luajit.org/download.html)），所有最高到 5.3 的 PUC-Rio Lua 版本均已 EOL (https://lua.org/versions.html)（“Lua 5.3 将不再有后续版本。”——注意，截至 2026 年 8 月，这句话还没有适用于 Lua 5.4；通常在下一个主要 Lua 5.x 发布一段时间后，还会有一个最终版本发布）。 如果 Roberto 和 Mike 都在让解释器 EOL，那么也许我们也应该对库做同样的事情。如果人们真的想使用非常非常老的 Lua 版本，那么他们也应该使用非常非常老的配套生态系统版本，而不是强迫维护者一直支持 20 多年的遗留系统。