mirror of https://github.com/axmolengine/axmol.git
71 lines
2.6 KiB
Markdown
71 lines
2.6 KiB
Markdown
# Contributing to axys
|
|
|
|
|
|
## For general questions
|
|
|
|
|
|
You can ask general questions by using:
|
|
|
|
- Forum (preferred way): https://github.com/axys1/axys/discussions
|
|
|
|
## Reporting bugs
|
|
|
|
To report bugs, please use the [Issue Tracker](https://github.com/axys1/axys/issues)
|
|
|
|
Steps to report a bug:
|
|
* Open the [url](https://github.com/axys1/axys/issues/new)
|
|
* 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](http://progit.org/book/) , especially the section on [Contributing to a project:Small/Large Public Project](http://progit.org/book/ch5-2.html#public_small_project) )
|
|
|
|
- Download the latest axys develop branch from github:
|
|
|
|
```
|
|
$ git clone git://github.com/axys1/axys.git
|
|
$ cd axys
|
|
$ 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 “axys”
|
|
- 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 [axys C++ Coding Style][1]
|
|
- For Python code follow the [PEP8 guidelines][3]
|
|
- 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.
|
|
|
|
__TBD__: Is this applicable for big features ? What is the best way to merge big features ?
|