-
Notifications
You must be signed in to change notification settings - Fork 234
Description
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:
- Put the openresty extensions under an optional flag. I need to think about it more seriously and make suggestions/PRs in Move openresty-specific language extensions under a special configuration? #63
- Start development on the master branch
- Start making release tarballs
Then there are secondary features that would be highly desirable for distributions:
- Release branches (v2.1, v2.2, etc.)
- Testsuite integrated into the main repository so that distributions can run
make checkin their %check targets for testing. I have PR Incorporate LuaJIT-test-cleanup into the main repository #78 open for this.
Branches
To start development on the master branch, I propose the following:
- Make a v2.0 branch that tracks the current master branch. This is where v2.0 fixes go in as needed
- Keep the v2.1 branch as is and make a release tarball (2.1.0) for distributions to pick up
- 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.