Make luajit2 into a fully supported project with releases

[openresty]

Make luajit2 into a fully supported project with releases

[SoniEx2]

If this is indeed the most active and most used fork of LuaJIT then perhaps also consider the idea of a project commit.

Ideally that project commit would go as upstream as possible, but sometimes we need to make tradeoffs. It'll mean some forks won't be able to participate but I still think this'll be a good thing, after all merging is easy.

The idea of a project commit is to group together some forks with some shared but easy to parse metadata between them. (yeah, I could've gone for an "take newest readme shared between two forks" approach but w/e. that would mean developers wouldn't be able to consent to other forks taking over development effort and I'm not sure that would be legal.)

LuaJIT is dead. it can't be killed further. something like GAnarchy could actually be beneficial here.

[XVilka]

Isn't the better course of action now switch to the MoonJIT instead?

[agentzh]

@siddhesh Sorry I just saw this one. I agree with formal new releases. We'd think more about release number scheme though. We are currently using version numbers like v2.1-20190510. I'm fine with the branch changes and documentation changes you proposed. We can even have a website for it.

[siddhesh]

Sounds good if you want to do a distro package for luajit2. I'll need to check on the version numbering mechanism, since that may need to follow a specific standard; I'll let you know.

EDIT: To clarify, I am already using moonjit v2.1 as base for luajit packages since it avoids extensions and is hence close to clean luajit + bugfixes. That is why I suggest a luajit2 package. Alternatively, we could merge moonjit v2.1 development into luajit2 in a manner that all luajit2 extensions go under a build flag. What would you prefer?

[agentzh]

@siddhesh Sure, we can do distro package for luajit2. All our extensions can go under a build flag. No problem with that. I prefer a single branch, which makes maintenance easier.

[siddhesh]

@agentzh great, so here's the plan:

1. Put all openresty extensions under a build flag
2. Merge in moonjit patches (AFAICT it's just docs and testsuite right now)
3. Use luajit2 releases as base for the Fedora luajit package with OR extensions disabled
4. Propose a new package luajit2 with OR extensions enabled

This may take a while but should give us a more long term solution.

[agentzh]

@siddhesh OK, your plan sounds good to me. It's just that the moonjit patches still need to go through the pull request/code review process before they can be merged into our repo's mainline branch :)

[jnozsc]

Thanks for pushing on this.

Question, which project should be considered as an activity maintained alternative of luajit? moonjit or this luajit2?

[siddhesh]

Both projects have slightly different goals. Neither are officially blessed, so it's really your call which project you consider suitable for your needs.

luajit2, as of today, aims to stay close to LuaJIT/LuaJIT and have extensions on top that focus on openresty.

moonjit v2.1.x stays close to LuaJIT/LuaJIT and does not have openresty extensions and is strictly for those who want to stay close to LuaJIT/LuaJIT but want fixes and architecture enablement that LuaJIT/LuaJIT doesn't. I wish to merge this into luajit2 since goals are overlapping and perhaps we could find a way to make a vanilla configuration without openresty extensions.

moonjit 2.x (i.e. 2.2 and later) breaks away from LuaJIT/LuaJIT and will try to get closer to Lua instead.

[jnozsc]

Thanks.

My case is I need a stable release package for luajit 2.1 branch. Details in this ticket LuaJIT/LuaJIT#563

Based on your comment, I would like to consider openresty/luajit2 is the good candidate, since it will keep compatible with luajit, and I look forward a stable release of it.

[XVilka]

For anyone who will find this issue but is not aware, that MoonJIT project is dead. Openresty LuaJIT2 is now being used by Linux distributions instead, for example Alpine.