🔗 The Lua community needs to learn to move on

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.

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.

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. 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.

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. 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.

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.

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.

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. 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.

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.

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. 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).

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.

Follow

🐘 Mastodon ▪ RSS (English), RSS (português), RSS (todos / all)

Last 10 entries

  • The Lua community needs to learn to move on
  • Aniversário do Hisham 2026
  • Aniversário do Hisham 2025
  • The aesthetics of color palettes
  • Western civilization
  • Why I no longer say "conservative" when I mean "cautious"
  • Sorting "git branch" with most recent branches last
  • Frustrating Software
  • What every programmer should know about what every programmer should know
  • A degradação da web em tempos de IA não é acidental