The Lua community needs to learn to move on

Lua 社区需要学会向前看

This could be a long blog post, but I’ll try to make it a short one, basically expanding on a GitHub comment I just posted. 这本可以是一篇很长的博文，但我会尽量写得简短些，基本上是对我刚刚发布的一条 GitHub 评论的扩展。

Recently, Mike Pall deleted some tags for old LuaJIT versions from his upstream GitHub repo. That is a pretty nuclear option for forcing people to upgrade, and in normal circumstances it would be seen as a very, err, unfriendly move in any FOSS situation. 最近，Mike Pall 从他的上游 GitHub 仓库中删除了一些旧版 LuaJIT 的标签。这是一种强制用户升级的“核选项”，在正常情况下，这在任何开源（FOSS）环境中都会被视为一种非常、呃，不友好的举动。

But I can see the frustration he’s probably coming from. I know there are tons of projects out there stuck in tags like luajit-2.1.0-beta3 for ages. He’s most likely getting bug reports for bugs fixed over ten years ago. 但我能理解他为何如此沮丧。我知道外面有无数项目长期停留在 luajit-2.1.0-beta3 这样的标签上。他很可能还在收到十多年前就已经修复的 Bug 报告。

I know because it’s the same in the LuaRocks world, where we keep getting bug reports for LuaRocks 2.0.8 from 2012 because distros haven’t updated them. I’ve also been on the other side and I know how taxing it is for distro maintainers, so I’m not pointing fingers. I’m just saying that maintenance and getting people to update is hard. 我深有体会，因为在 LuaRocks 的世界里也是如此。我们不断收到关于 2012 年 LuaRocks 2.0.8 版本的 Bug 报告，原因仅仅是发行版没有更新它们。我也曾站在发行版维护者的角度，知道这有多么繁重，所以我并不是在指责谁。我只是想说，维护工作以及推动人们更新确实很难。

This is, however, an especially difficult problem in the Lua community. Ever since the Lua/LuaJIT split around 5.2 (gosh, that was… 15 years ago!?), the community has gotten in this paralyzing tendency of supporting old versions forever, even when upstream doesn’t support them anymore. 然而，这在 Lua 社区中是一个特别棘手的问题。自从 Lua 和 LuaJIT 在 5.2 版本左右分道扬镳以来（天哪，那已经是……15年前的事了！？），社区就陷入了一种瘫痪的倾向：即使上游不再提供支持，大家也依然无限期地支持旧版本。

People making Lua libraries keep testing their packages against Lua 5.1, 5.2, 5.3, 5.4 and now 5.5; then LuaJIT 2.1, sometimes the OpenResty variant as well, and now 3.0. 开发 Lua 库的人们不断地针对 Lua 5.1、5.2、5.3、5.4 以及现在的 5.5 进行测试；接着是 LuaJIT 2.1，有时还有 OpenResty 变体，现在又加上了 3.0。

I understand that Lua is an embeddable language and if you make a decision in a point in time to bundle, say Lua 5.2 in your app and you build a plugin ecosystem around it, then you’re married to it forever. But then that’s your app’s ecosystem to take care. 我理解 Lua 是一门可嵌入语言，如果你在某个时间点决定将 Lua 5.2 捆绑到你的应用中，并围绕它构建了一个插件生态系统，那么你就注定要与它绑定在一起。但那是你自己的应用生态系统，需要你自己去维护。

For Lua as an extensible language (that is, an interpreter + libraries), the story should be different, and it should be more like any other dynamic/scripting language out there. We should really be (gradually?) moving into supporting only the latest PUC-Rio Lua and the latest LuaJIT, at best. 但对于作为可扩展语言（即解释器 + 库）的 Lua 而言，情况应该有所不同，它应该更像其他任何动态/脚本语言。我们真的应该（逐步？）转向只支持最新的 PUC-Rio Lua 和最新的 LuaJIT，最多仅此而已。

I know why we ended up where we are. I know the history because I was there: with the Lua/LuaJIT schism, people wanted to support both environments, and targeting 5.1 was a good way to support both. And then 5.2, 5.3, etc. came along and people wanted to keep supporting the latest PUC-Rio Lua, but still felt tied to the 5.1 anchor. 我知道我们为何会走到今天这一步。我了解这段历史，因为我亲历其中：随着 Lua 和 LuaJIT 的分裂，人们希望同时支持这两种环境，而以 5.1 为目标是一个兼顾两者的好方法。后来 5.2、5.3 等版本相继出现，人们既想支持最新的 PUC-Rio Lua，又感到被 5.1 这个锚点所束缚。

I’m sure I’m partly to blame for this because I engaged in this and helped others, by maintaining compat-5.3, itself an evolution of compat-5.2, with a history tracing all the way back to compat-5.0, which predates my involvement with Lua… and then we’re talking over 20 years ago. 我肯定也要为此承担部分责任，因为我参与其中并帮助了他人，我维护了 compat-5.3，它本身就是 compat-5.2 的演进，其历史甚至可以追溯到我接触 Lua 之前的 compat-5.0……那可是 20 多年前的事了。

My small contribution to try to undo this, nowadays, is Teal, a language that aims to be to Lua what TypeScript is to JavaScript: it not only aims to bring types to the language, but it also aims to bridge the version gaps. You can write Teal once, and then generate Lua with –gen-target=5.1 all the way to –gen-target=5.5. Hopefully this will help untie writers of Lua code from the Lua 5.1 anchor. 如今，我为扭转这一局面所做的一点微小贡献是 Teal。这门语言之于 Lua，正如 TypeScript 之于 JavaScript：它不仅旨在为语言引入类型，还旨在弥合版本间的鸿沟。你可以编写一次 Teal 代码，然后通过 --gen-target=5.1 一直到 --gen-target=5.5 来生成对应的 Lua 代码。希望这能帮助 Lua 代码编写者摆脱 Lua 5.1 的束缚。

But even if you’re not using Teal, and you’re a Lua library author, consider doing what Roberto and Mike are doing: they do EOL their language versions. 但即使你不使用 Teal，如果你是一位 Lua 库作者，也请考虑效仿 Roberto 和 Mike 的做法：他们确实会对其语言版本进行生命周期终止（EOL）。

LuaJIT 1.0 is EOL, LuaJIT 2.0.0 is EOL (there’s a 2.0 bugfix branch, but the old tarballs are EOL), and all PUC-Rio Lua versions up to 5.3 are EOL (”There will be no further releases of Lua 5.3.” — note that as of August 2026, this is not said of Lua 5.4; there’s usually one last release a while after the next major Lua 5.x comes out). LuaJIT 1.0 已 EOL，LuaJIT 2.0.0 已 EOL（虽然有一个 2.0 的 Bug 修复分支，但旧的压缩包已 EOL），所有 5.3 及之前的 PUC-Rio Lua 版本也都已 EOL（“Lua 5.3 不会再有后续版本发布。”——请注意，截至 2026 年 8 月，Lua 5.4 尚未如此声明；通常在下一个 Lua 5.x 大版本发布后的一段时间内，还会有一个最终版本）。

If Roberto and Mike are EOLing the interpreters, maybe we should be doing the same for the libraries. If people really want to be using very very old versions of Lua, they should be using very very old versions of the supporting ecosystem as well, and not forcing maintainers into supporting 20+ years of legacy at all times. 如果 Roberto 和 Mike 都在对解释器进行 EOL，也许我们也应该对库采取同样的做法。如果人们真的想使用非常非常古老的 Lua 版本，他们也应该使用配套生态系统中非常非常古老的版本，而不是强迫维护者时刻支持 20 多年的遗留代码。