Note, that probably part of this is the version of Lua WMF servers have available on the installed Debian version. There are plans to upgrade to Stretch (version 9), see T174431: Upgrade mw* servers to Debian Stretch (using HHVM) which may potentially block this

I do note liblua5.2 seems to be available on a few hosts checked, and it's in debian stable (as is liblua5.1)

So, I suspect, there might be scope to be able to build luasandbox against newer lua (or, at least, not preventing it), support for 5.1 possibly isn't going to be dropped anytime soon. However, I'm not sure (I'm sure someone will correct me) why we're still using 5.1 if 5.2 is available on WMF servers

The main blocker, as far as I know, is that 5.2 completely changed how function environments work and function environments are heavily used for our sandboxing. To be able to use 5.2, someone would have to redo the sandboxing and it would have to be reviewed for security.

To quote @tstarling:

For some background material about why I don't like the idea of moving to Lua 5.2, you could read:

http://lua-users.org/lists/lua-l/2012-02/msg00127.html

It was mentioned there that LuaJIT is based on Lua 5.1 -- that is still the case.

http://lua-users.org/lists/lua-l/2012-02/msg00150.html

"And the second important point is, that it's worthy to sometimes look at each Lua version as a totally unrelated language, "only accidentally bearing a somewhat similar name". It is not considered as something "bad" if you stick with your chosen version of Lua forever in your product (although this surely also has some drawbacks) [1][2]. You can even consider taking it sideways, by adding some patches etc."

So I would mark this as declined, but he also said (in 2014):

Like I said at the start of this project, maybe in a decade or so. Unless there is some actual reason to want to do it?

So marking as stalled for re-evaluation in 2024.

Lua 5.4 is now available as well. It would be nice to see it use the latest version.

To quote @tstarling:

For some background material about why I don't like the idea of moving to Lua 5.2, you could read:

http://lua-users.org/lists/lua-l/2012-02/msg00127.html

It was mentioned there that LuaJIT is based on Lua 5.1 -- that is still the case.

http://lua-users.org/lists/lua-l/2012-02/msg00150.html

"And the second important point is, that it's worthy to sometimes look at each Lua version as a totally unrelated language, "only accidentally bearing a somewhat similar name". It is not considered as something "bad" if you stick with your chosen version of Lua forever in your product (although this surely also has some drawbacks) [1][2]. You can even consider taking it sideways, by adding some patches etc."

So I would mark this as declined, but he also said (in 2014):

Like I said at the start of this project, maybe in a decade or so. Unless there is some actual reason to want to do it?

So marking as stalled for re-evaluation in 2024.

It's now almost 2024 :) 5.4 is now available with new features such as const.

I am assuming this project is dead (which is super sad). It was extremely nice having something to easily manipulate data from dynamic datasets without hardcoding it into the application.

Which "project" in this case are you assuming is dead?

Do we have any specific list of features that "we" as a community need/want?

Upgrading for the sake of upgrading isn't really a great reason, but if we have some better use cases/similar...

Requoting from above

To quote @tstarling:

For some background material about why I don't like the idea of moving to Lua 5.2, you could read:

http://lua-users.org/lists/lua-l/2012-02/msg00127.html

It was mentioned there that LuaJIT is based on Lua 5.1 -- that is still the case.

http://lua-users.org/lists/lua-l/2012-02/msg00150.html

"And the second important point is, that it's worthy to sometimes look at each Lua version as a totally unrelated language, "only accidentally bearing a somewhat similar name". It is not considered as something "bad" if you stick with your chosen version of Lua forever in your product (although this surely also has some drawbacks) [1][2]. You can even consider taking it sideways, by adding some patches etc."

@tstarling Got any updated opinions about this in 2025?

Lua 5.1 has been dead since 2012. Its not about "new features". Its about using a maintained version. A lot of distros don't even allow installing Lua 5.1 without enabling legacy repos. For example, homebrew has removed it (linked to 5.3 as 5.1 completely 404s now. Debian still has 5.1 and is only getting minor build patches.

I wouldn't even say target 5.2 as thats not supported either. 5.4 is the only supported Lua release right now.

As for the "project", I am talking about the LuaSandbox project. And those cited mailing lists are dead links.

@tstarling Got any updated opinions about this in 2025?

I briefly talked with Tim about this last year, my recollection is that users need to articulate what newer Lua features they want and how they'd use them (correct me if I'm misremembering please!) to justify an upgrade; I'd personally suggest starting a wiki page for people to collaborate on. IIRC some Lua 5.2 features were already backported. Upgrading requires re-auditing the entire security of whichever version of Lua, which is a non-trivial endeavor.

Lua 5.1 has been dead since 2012. Its not about "new features". Its about using a maintained version. A lot of distros don't even allow installing Lua 5.1 without enabling legacy repos. For example, homebrew has removed it (linked to 5.3 as 5.1 completely 404s now. Debian still has 5.1 and is only getting minor build patches.

It's unfortunate that homebrew removed it, but is there actual maintenance that's needed for it? It's basically a finished project at this point. It probably would be useful to create a new unofficial Lua 5.1 upstream that collects the various distro patches that are floating around and provides some binary builds but it's pretty minimal maintenance.

@Legoktm, as for me as Lua developer it's annoying to dig into ancient Lua docs to write the ancient code. But technically I'm completely fine with the set of features that Lua 5.1 provides.

But still. How many years we need to wait more to make the current Lua engine totally incompartible in syntax with the actual Lua version? "Totally incompartible" I mean when to upgrade the engine we will need to completely drop everything written in Lua before and write it again from the scratch.
"Finished project" but why not COBOL then? It's also finished project. I speak COBOL and also fine with it. :)

Let's make the syntax transition between Lua versions as soft as possible. I suggest to start with 5.2 while it's not too late.
These transitions may happen a bit more often than Lua developers makes a new major version. Then finally Wikis will support the current Lua.

I am implementing wiki stuff on a regular base.

• I do not feel any need to be in line with any current version in the outer world.
• The codes I know are limited to Wiki page transclusion, by #invoke: in the end, providing better outcome than available via wikitext template syntax.
• There is no need to apply this outside of a wikitext page.
• I do not need any code from outside of WMFverse. There might be code examples for a few standard tasks, but they would be ported once into wikitext framework, perhaps with some other solutiuons for unavailable syntax. Much less efforts than upgrading.

There is a doc of 5.1 on my hard disk, and I do know it from cerebral memory.

• A copy should be available at WMF.

Some interesting new features, related to multibyte strings:

• Lua 5.2 would let us use hexadecimal byte codes in strings, whereas we currently have to rely on decimal byte codes, which are very uncommon. Example: we could replace the very unusual \194\160 with \xC2\xA0.
• Lua 5.3 would even let us use Unicode code points in strings. Example: \u{A0}.
  • These code points are converted into their corresponding sequences of UTF-8 bytes (as outlined here). Keep in mind, they remain multibyte strings and come with all the associated caveats when using native string.* functions.

References:

• Lua 5.2:
  • hex and \z escapes in strings
  • \0 in patterns (addresses this issue)

• Lua 5.3:
  • basic utf-8 support

To provide an example, on frwiki we have a Langue.nonLatin() method that works on multibyte strings. Lua 5.3 would let us change this:

local pattern = '[^'
    .. '%z'                        -- U+0000 (UTF-8 00), cas particulier qu'il faut représenter avec %z
    .. '\001-\205\175'             -- U+0001 (UTF-8 01) à U+036F (UTF-8 CDAF)
    .. '\225\180\128-\225\187\191' -- suppléments phonétique, diacritiques et latin : U+1D00 (UTF-8 E1B480) à U+1EFF (UTF-8 E1BBBF)
    .. '\226\128\128-\226\177\191' -- espace, indices, monnaies et symboles divers : U+2000 (UTF-8 E28080) à U+2C7F (UTF-8 E2B1BF)
    .. '\234\156\160-\234\159\191' -- latin étendu D : U+A720 (UTF-8 EA9CA0) à U+A7FF (UTF-8 EA9FBF)
    .. ']'

To this:

local pattern = '[^'
    .. '\u{0}-\u{36F}'     -- U+0000 (UTF-8 00) à U+036F (UTF-8 CDAF)
    .. '\u{1D00}-\u{1EFF}' -- suppléments phonétique, diacritiques et latin : U+1D00 (UTF-8 E1B480) à U+1EFF (UTF-8 E1BBBF)
    .. '\u{2000}-\u{2C7F}' -- espace, indices, monnaies et symboles divers : U+2000 (UTF-8 E28080) à U+2C7F (UTF-8 E2B1BF)
    .. '\u{A720}-\u{A7FF}' -- latin étendu D : U+A720 (UTF-8 EA9CA0) à U+A7FF (UTF-8 EA9FBF)
    .. ']'

I have reviewed the lists of new features (Lua 5.2, Lua 5.3, Lua 5.4), and apart from the hexadecimal and Unicode escapes I mentioned earlier, I don't see anything particularly compelling. That said, I believe these escapes alone would justify implementing a newer Lua version.