Skip to content
This repository has been archived by the owner on Sep 19, 2021. It is now read-only.

Latest commit

 

History

History
70 lines (41 loc) · 2.25 KB

CONTRIBUTING.md

File metadata and controls

70 lines (41 loc) · 2.25 KB
Raw

Thank you for contributing!

Bug report or new feature proposal

Create a new issue from here.

Pull request

  1. Create a new issue.
  2. Fork this repository and clone the forked one.
  3. Set up upstream branch: git remote add upstream https:://github.com/YOUR_ACCOUNT/elonafoobar.
  4. Update local develop: git checkout develop && git pull upstream develop.
  5. Create your working branch from develop. Naming conventions are as follows:
  • Prepend feature/, fix/ or refactor/ to the short summary of your changes. For example,
    • feature/add-lua-module
    • fix/map-tile-glitch
    • refactor/remove-global-variables
  1. Work and commit your changes. Small commits are prefered.
  2. Run make format or nmake -f Makefile.win format to format your changed source code.
  • Note: If your changed source code is not formatted consistently, continuous integration will not pass.
  1. Update local develop again.
  2. Rebase: git checkout YOUR_WORKING_BRANCH && git rebase develop.
  3. Push the working branch to your repo: git push origin YOUR_WORKING_BRANCH.
  4. Create a new pull request.
  5. Your pull request is reviewed and fix problems if needed.
  6. Your pull request is merged.

If your changes are big or you need help, you can send a Draft Pull Request.

Lua API features

  1. Create a new file named module_[ModuleNameInPascalCase].cpp under src/elona/lua_env/api/modules.
  2. Add functions inside the appropriate namespace.
  • Add overrides for functions taking Position so two ints can be passed instead.
  1. Set the binding on the correct table in elona::lua::LuaApi::bind().
  2. Update .luacheckrc with the new table value.
  3. Run make docgen to generate corresponding LDoc file. (Rust toolchains are required)
  4. Add tests inside tests/lua_api.cpp.
  5. Provide a playtest script demonstrating the API in the pull request.

Branching rules

We use Git flow. See http://nvie.com/posts/a-successful-git-branching-model/ for details.

Code style

See CODE_STYLE.md.

Versioning convention

Application

Ignore Semantic Versioning.

Built-in mods

Follow Semantic Versioning. Each mod has its own version, not synchronized with each other.