Skip to content

Prepare a new v12 tag that sets Lua 5.5 as default version#5

Merged
luau-project merged 9 commits into
luarocks:masterfrom
luau-project:prepare-v12
Jul 10, 2026
Merged

Prepare a new v12 tag that sets Lua 5.5 as default version#5
luau-project merged 9 commits into
luarocks:masterfrom
luau-project:prepare-v12

Conversation

@luau-project

Copy link
Copy Markdown
Collaborator

Description

CC @hishamhm

Lua 5.5 and LuaRocks 3.13.0 were updated 7 months ago, then I think it is a reasonable time to bump versions here.
Thus, there were minor changes preparing to push a new tag on both luarocks-gh-actions-* repos accounting for Lua 5.5 and LuaRocks 3.13.0.

Changes

Note

If there is no objection, I'll merge this PR and push a new tag tomorrow.

Question

I can see that both repos have issues disabled. Since the code on such repos have diverged enough from upstream, what do you think about enabling that feature so users can report them?

Comment thread .github/workflows/test.yml Outdated
@Aire-One

Aire-One commented Jul 9, 2026

Copy link
Copy Markdown

I can see that both repos have issues disabled. Since the code on such repos have diverged enough from upstream, what do you think about enabling that feature so users can report them?

IIRC, it was disabled as a "use this Actions at your own risks outside the Luarocks/Teal projects". This, and the slower maintenance on the forks (Leafo already have the release for Lua 5.5 and Luarocks 3.13.0) is the reason I switched back to Leafo upstream in Awesome workflow (awesomeWM/awesome#4103).

I guess enabling the issues back only makes sense if there are maintainers to work on the forks, and the forks actually bring something new to the table compared to the Leafo upstreams. Since Leafo updated its Actions, the forks feel like duplication of work.

@luau-project

Copy link
Copy Markdown
Collaborator Author

IIRC, it was disabled as a "use this Actions at your own risks outside the Luarocks/Teal projects".

I think this comment ( lgi-devs/lgi#324 (comment) ) by Hisham describes well the history about this repo when leafo's action was failing to install LuaJIT due HTTP 404 error, quoting here for brevity:

Aire-One That fork was only meant for making a PR to upstream, not to be added of the list of "things that Hisham mantains (poorly)" 😅

But I understand the role that it is currently taking. So, I have transferred both gh-actions-lua and gh-actions-luarocks from my personal account to the luarocks org. Ideally, we should be able to eventually resync with leafo's upstream and have it become just a mirror, but until then for all intents and purposes luarocks/gh-actions-lua and luarocks/gh-actions-luarocks are the Actions recommended by the LuaRocks project.

Being the Actions recommended by the LuaRocks project, it carries the LuaRocks brand with it. Even though I have permissions to push changes to this and the other gh-actions repo, I usually avoid to do so. However, if Hisham explicitly allows me to push changes to these gh-actions repos without waiting for his approval, I would fix many issues (that I am aware of) and update these repos pretty quickly, maintaining the same API.

This, and the slower maintenance on the forks (Leafo already have the release for Lua 5.5 and Luarocks 3.13.0) is the reason I switched back to Leafo upstream in Awesome workflow (awesomeWM/awesome#4103).

I think this would be another selling point to enable issues in these repos. That way, you or any other user could open an issue requesting the version bump on gh-actions, and the update could be discussed earlier.

In other scenarios, I'd have pushed the changes to update these repos. On the other hand, this update (Lua 5.5) brought the "read-only control variable" that would break a considerable number of important repos (busted, luacov, luacheck, argparse, lua-compat53, ...). So, if I had pushed Lua 5.5 version bump at the beginning, I guess that many CI users would have their actions instantly broken.

I guess enabling the issues back only makes sense if there are maintainers to work on the forks, and the forks actually bring something new to the table compared to the Leafo upstreams. Since Leafo updated its Actions, the forks feel like duplication of work.

People started to use gh-actions from LuaRocks because leafo's action was consistently failing to install LuaJIT when Mike Pall removed the tarballs from luajit's website. But now that leafo's actions are up-to-date, on Unix, it is a matter of choice. The biggest difference shows up when you try to install LuaRocks on Windows, because leafo's gh-actions-luarocks is Unix-only AFAIK.

@Aire-One

Copy link
Copy Markdown

I think this comment (...) by Hisham describes well the history about this repo
[...]
Being the Actions recommended by the LuaRocks project,

To be fair, I really don't read the Hisham comment as a recommendation to use the forks. He explicitly says he doesn't want to maintain it, and wants to merge back to Leafo. And reality is that this repo didn't receive so much love, while Leafo merged fixes and produced releases to unblock usage of the upstream Actions.

As a user, I'm lost in the blur. The Lua ecosystem move slowly and when 2 forks go their way, it's not obvious what to do. Especially when they require multiple months to update to the new version.

Please don't take this as a criticism. I really appreciate the work you are doing here to maintain this Actions. What I need is a repository that is kept maintained (so it works and get updates) and where issues/PRs get feedbacks (so the repo is kept alive with its users). I'm happy to see you stepping in as a maintainer here, it's a good sign that things will be moving again on this repo.

My inquiry from my previous comment was more a "mehh now we're back at 2 updated forks, and as a user, it's still not clear what to do at this point in time".

On the other hand, this update (Lua 5.5) brought the "read-only control variable" that would break a considerable number of important repos (busted, luacov, luacheck, argparse, lua-compat53, ...). So, if I had pushed Lua 5.5 version bump at the beginning, I guess that many CI users would have their actions instantly broken.

IMO, this is a non-problem :

  • It is a known bad practice to pin Actions to "main/latest", and you should instead pin the version to use (GitHub documentation even recommends to "Pin actions to a full-length commit SHA" and "to a tag only if you trust the creator" because they are moving targets: https://docs.github.com/en/actions/reference/security/secure-use#using-third-party-actions).
  • Projects that want to update to the latest version of the Actions, but doesn't yet support the latest Lua version should use the luaVersion option (all the projects you list already use it with matrix, except lua-compat53 that doesn't even use the Actions).

But also, projects need the tools first. Updating to the latest Lua version requires your CI to run it. The Actions cannot wait for other projects to update, it's the tool that they need to run their CI on and work on the breaking changes. Again, I switched back to Leafo on the Awesome repo because I wanted to have the tools to run the CI with Lua 5.5.

Co-authored-by: Christian Clauss <cclauss@me.com>
@luau-project

Copy link
Copy Markdown
Collaborator Author

As a user, I'm lost in the blur. The Lua ecosystem move slowly and when 2 forks go their way, it's not obvious what to do. Especially when they require multiple months to update to the new version.

...

My inquiry from my previous comment was more a "mehh now we're back at 2 updated forks, and as a user, it's still not clear what to do at this point in time".

I know how it feels trying to follow the standard. Like I said earlier, if you are running on Unix-only, such actions have most likely the same behavior.

My opinion (guess): I might be mistaken, but I don't see these gh-actions repos getting merged back on leafo's repo, nor going into unmaintained state, because many lunarmodules repos use them, and they also serve as support actions in the test suite of the luarocks CLI repo.

Please don't take this as a criticism. I really appreciate the work you are doing here to maintain this Actions. What I need is a repository that is kept maintained (so it works and get updates) and where issues/PRs get feedbacks (so the repo is kept alive with its users). I'm happy to see you stepping in as a maintainer here, it's a good sign that things will be moving again on this repo.

I didn't, and thanks for your words. Regarding to actively replying to issues / PRs, I don't have the rights to turn on issues here, but anyone can open a PR. For instance, the latest commit on these repos was from Tieske's PR.

On a (shameless 😊) side note, if you feel inclined, on my gh acc, I created an action a few months ago with similar functionality to setup Lua / LuaRocks.

IMO, this is a non-problem :

...

But also, projects need the tools first. Updating to the latest Lua version requires your CI to run it. The Actions cannot wait for other projects to update, it's the tool that they need to run their CI on and work on the breaking changes. Again, I switched back to Leafo on the Awesome repo because I wanted to have the tools to run the CI with Lua 5.5.

Indeed, makes sense. I'll keep this POV for future Lua / LuaRocks updates on these gh-actions repos.

All in all, one week has gone since I opened this PR, and I think it is time enough for everyone involved to have been made aware. Since I didn't receive any objections, I'm proceeding to push a new tag on both gh-actions repos.

@luau-project
luau-project merged commit fc6f8de into luarocks:master Jul 10, 2026
76 checks passed
@luau-project
luau-project deleted the prepare-v12 branch July 10, 2026 15:40
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants