2022-03-18 11:01:40 +08:00
# Contributing to adxe
2019-11-23 20:27:39 +08:00
## For general questions
You can ask general questions by using:
2022-03-18 11:01:40 +08:00
- Forum (preferred way): https://github.com/adxeproject/adxe/discussions
2019-11-23 20:27:39 +08:00
## Reporting bugs
2022-03-18 11:01:40 +08:00
To report bugs, please use the [Issue Tracker ](https://github.com/adxeproject/adxe/issues )
2019-11-23 20:27:39 +08:00
Steps to report a bug:
2022-03-18 11:01:40 +08:00
* Open the [url ](https://github.com/adxeproject/adxe/issues/new )
2019-11-23 20:27:39 +08:00
* 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 ) )
2022-03-18 11:01:40 +08:00
- Download the latest adxe develop branch from github:
2019-11-23 20:27:39 +08:00
```
2022-03-18 11:01:40 +08:00
$ git clone git://github.com/adxeproject/adxe.git
$ cd adxe
$ git checkout dev
2019-11-23 20:27:39 +08:00
```
- 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
2022-03-18 11:01:40 +08:00
- Send a “pull request” to user “adxe”
2019-11-23 20:27:39 +08:00
- 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:
2022-03-18 11:01:40 +08:00
- For C++ code follow the [adxe C++ Coding Style][1]
2019-11-23 20:27:39 +08:00
- 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 ?