Contribution Guide
April 24, 2025 · View on GitHub
We highly appreciate your contributions to Kuikly, whether it's raising an issue, fixing a bug, or submitting a new feature. Before submitting your contribution, please take a moment to read the following guidelines:
Issue Reporting Guidelines
The project collects issues and requirements through Issues.
-
Before raising an issue, please check if someone else has already proposed a similar feature or problem.
-
When raising an issue, please describe the problem in as much detail as possible, including steps to reproduce, code snippets, screenshots, etc.
Bug Report
Describe the bug
A clear and concise description of what the bug is.
To Reproduce
Steps to reproduce the behavior:
- Go to '...'
- Click on '....'
- Scroll down to '....'
- See error
Expected behavior
A clear and concise description of what you expected to happen.
Screenshots
If applicable, add screenshots to help explain your problem.
Smartphone (please complete the following information):
- Device: [e.g. iPhone6]
- OS and version: [e.g. iOS 13.3.1]
- Kuikly SDK version: [e.g. 2.0.0]
- Additional context Add any other context about the problem here.
Feature Request
Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
Describe the solution you'd like
A clear and concise description of what you want to happen.
Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
Additional context
Add any other context or screenshots about the feature request here.
Pull Request Guidelines
Branch Management
This project mainly includes the following three types of branches:
- main: A stable development branch that only accepts fully tested features or bug fixes. Releases are made directly from the main branch by tagging.
- feature: Named according to the feature/** rule, it is a feature development branch.
- bugfix: Named according to the bugfix/** rule, it is a daily bugfix branch.
Commit Messgage
Please follow the Angular Convention for commit messages:
- feat:New feature
- fix:Bug fix
- docs:Documentation changes
- style: Formatting changes (does not affect code execution)
- refactor:Code refactoring (neither a new feature nor a bug fix)
- test:Adding tests
- chore:Changes to the build process or auxiliary tools
Merge Reuqest
Please initiate a merge request via Merge Request. Before submitting an MR, please ensure:
- Checkout a topic branch from the relevant branch, e.g. main, and merge back against that branch.
- The code has been thoroughly tested and validated.
- The code complies with the project's coding standards.
- If it involves API changes, please update the API documentation.
- Link relevant issues or requirements.
Code Standards
This project adheres to the coding style guides provided by Google: Google's Style Guides
Version Numbering Convention
Version releases follow a three-part naming rule: major.minor.fix, e.g., 1.0.0
- major: Major version number, core baseline version.
- minor: Minor version number, used for releasing small feature modules.
- fix: Stage version number, used for bug fixes or partial code module optimizations.
For releasing alpha, beta, rc, etc., versions, append -[alpha|beta|rc] to the version number, e.g., 1.0.0-beta.
Special Note: Kuikly will use a higher version of Kotlin during the development process to leverage official capabilities, while the Kotlin version in business projects may be lower. Therefore, it is necessary to support multiple versions for business selection. Thus, the version number of the core library needs to include the Kotlin version as a distinction, e.g., 1.0.0-1.7.0, where 1.7.0 is the minimum Kotlin version required by the business project.