Make luajit2 into a fully supported project with releases

[siddhesh]

Given that the official repository for LuaJIT is now abandoned for almost a year, most people I know who are interested in the LuaJIT ecosystem are interested in seeing luajit2 become a first class project instead of a branch of LuaJIT.

To make this possible, the following goals need to be met:

1. Put the openresty extensions under an optional flag. I need to think about it more seriously and make suggestions/PRs in #63
2. Start development on the master branch
3. Start making release tarballs

Then there are secondary features that would be highly desirable for distributions:

1. Release branches (v2.1, v2.2, etc.)
2. Testsuite integrated into the main repository so that distributions can run make check in their %check targets for testing. I have PR #78 open for this.

Branches

To start development on the master branch, I propose the following:

1. Make a v2.0 branch that tracks the current master branch. This is where v2.0 fixes go in as needed
2. Keep the v2.1 branch as is and make a release tarball (2.1.0) for distributions to pick up
3. Merge v2.1 into master and then start putting all new patches into master going forward, making release branches and/or tarballs at a regular cadence, say, every 3 months.

Documentation

I propose that we convert the luajit HTML documentation into markdown so that it is convenient to read in github. We should also move the features mentioned in README.md into the main documentation and make README.md more about installation and development documentation.

Needless to say, I'm happy to help with one or more of these tasks. My intention is to propose a new package luajit2 to deprecate luajit in Fedora. That way I can add tarballs instead of having to host hundreds of patches.

[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 https://github.com/LuaJIT/LuaJIT/issues/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.