Skip to content

Latest commit

 

History

History
78 lines (55 loc) · 3.36 KB

CONTRIBUTING.md

File metadata and controls

78 lines (55 loc) · 3.36 KB
Raw

Contributing to Axmol Engine

General considerations

Providing correct and relevant information is key

When asking a question, reporting a bug, or submitting a patch, it is very important to write down clearly all the relevant information the reviewer may need. For a bug report, provide the steps to reproduce it; for a pull request, outline the changes made and the reasons behind them. This will assist the reviewers and make the process of improving Axmol smoother for everybody.

For questions

Please revise our FAQ and check the GitHub Discussions, your question may have been already answered.

If that is not the case, you can ask general questions by using:

Reporting bugs

To report bugs, please use the Issue Tracker.

Steps to report a bug:

  • Open the issues url
  • Add all the needed information to reproduce the bug, the information include
    • engine version
    • steps to reproduce the bug
    • some pseudocode
    • resources link if needed

Submitting patches

If you want to contribute code, please follow these steps:

(If you are new to git and/or GitHub, you should read Pro Git , especially the section on Contributing to a project:Small/Large Public Project )

  • Download the latest axmol develop branch from github:
$ git clone git://github.com/axmolengine/axmol.git
$ cd axmol
$ git checkout dev
  • Apply your changes in the recently downloaded repository
  • Commit your changes in your own repository
  • Create a new branch with your patch: $ git checkout -b my_fix_branch
  • Push your new branch to your public repository
  • Send a “pull request” to user “axmol”
  • It must be complete. See the definition below
  • It must follow the Releases rules. See the definition below

Only complete patches will be merged

The patch must be complete. And by that, we mean:

  • For C++ code follow the axmol C++ Coding Style
  • For Python code follow the PEP8 guidelines
  • Describe what the patch does
  • Include test cases if applicable
  • Include unit tests if applicable
  • Must be tested in all supported platforms [*]
  • Must NOT degrade the performance
  • Must NOT break existing tests cases
  • Must NOT break the Continuous Integration build
  • Must NOT break backward compatibility
  • Must compile WITHOUT warnings
  • New APIs MUST be easy to use, familiar to cocos2d-x users
  • Code MUST be easy to extend and maintain
  • Must have documentation: C++ APIs must use Doxygen strings, tools must have a README.md file that describe how to use the tool
  • Must be efficient (fast / low memory needs)
  • It must not duplicate existing code, unless the new code deprecates the old one
  • Patches that refactor key components will only be merged in the next major versions.

[*]: If you don't have access to test your code in all the supported platforms, let us know.

About branch management

Please read this announcement.