-
Notifications
You must be signed in to change notification settings - Fork 242
Contributing and code guidelines
This project follow the same guidelines of Kodi (xbmc) repository, here some basic points:
Pull request guidelines:
-
All developments occurs on the branch that reflect the last Kodi version under development (to match
master
branch on xbmc). If it needs backporting it can be done after it is at least approved on master. - Use a coherent commit history, when possible make sure each individual commit in your pull request is meaningful and organized in logical chunks. Tidy up and squash commits before submitting.
-
Be descriptive, but concise. The pull request and commits should have a useful title and follow the format:
[Component(s)] Short description...
where for component could be for example the name of the modified class or other relative contexts
if you are doing a backport add also "backport" as prefix:
[Backport][Component(s)] Short description...
something like this is not descriptive enough:
[README.md] Update
The pull request description should only contain information relevant to the change by using our PR template schema.
You can read detailed updated guidelines from this file CONTRIBUTING.md
This project follow the same code guidelines of Kodi (xbmc) repository, you can read updated code guidelines from this file CODE_GUIDELINES.md
We would also like to remind you other two points:
-
Return character, files must always be written by using the UNIX return character
LF
. - Code format style, when you apply a code change please always format your code by using the Clang-Format style. For example Visual Studio can automatically detect our Clang-Format rules and you can use CTRL+K+F shortcut keys to automatically apply the code style to the selected code lines.
A backport consists in to apply a recent update or fix to an older Kodi version. Generally only fixes are allowed to be backported, and only for the version prior to the one currently under development (relative to master branch on xbmc repository). Other specific situations can be evaluated by the team, so before investing time on a backport we recommend you to open an Issue to propose it.
User Documentation
Developer Documentation
- Integration
- Integration DRM
- Integration DRM (old)
- Stream selection types properties
- How to test a stream
- Test samples python addon
- How to provide custom manifest and license
- Supported containers and codecs
- Verified Media Path (VMP)
- Set resolution limits for DRM streams
- Custom DASH manifest tags
- Audio Subtitles track properties
- Dev. FAQ
- Widevine ARM64 support
- Add‐on WIP status
Development