|
1 | | -# Contributing |
| 1 | +# Contributing to RE-UE4SS |
| 2 | + |
| 3 | +Thank you for taking the time to contribute! |
| 4 | + |
| 5 | +All types of contributions are encouraged and valued. This guide outlines the process and guidelines for contributing to the project. |
| 6 | + |
| 7 | +## Table of Contents |
| 8 | + |
| 9 | +- [Reporting issues](#reporting-issues) |
| 10 | +- [Pull Request Guidelines](#pull-request-guidelines) |
| 11 | +- [Development Workflow](#development-workflow) |
| 12 | +- [Code Style Guidelines](#code-style-guidelines) |
| 13 | +- [Commit Message Guidelines](#commit-message-guidelines) |
| 14 | +- [Upgrade Guidelines](#upgrade-guidelines) |
| 15 | +- [License](#license) |
| 16 | + |
| 17 | +## Reporting Issues |
| 18 | + |
| 19 | +Before you ask a question, it is best to search for existing [issues](https://github.com/UE4SS-RE/RE-UE4SS/issues) and read the available [documentation](https://docs.ue4ss.com/). |
| 20 | + |
| 21 | +If you still need clarification: |
| 22 | +- Open an [issue](https://github.com/UE4SS-RE/RE-UE4SS/issues) using the correct template |
| 23 | +- Provide as much context as you can about what you're experiencing |
| 24 | +- Provide project and platform versions (OS, etc.) |
| 25 | +- If the issue is build related, provide toolchain information (compiler version, etc.) |
| 26 | +- Provide UE4SS.log whenever it's available, even if it doesn't seem useful |
| 27 | + |
| 28 | +> **Security Issues**: Never report security-related issues, vulnerabilities or bugs including sensitive information to the issue tracker. Instead, please email sensitive bugs to <security@ue4ss.com>. |
| 29 | +
|
| 30 | +## Pull Request Guidelines |
| 31 | + |
| 32 | +### General Requirements |
| 33 | + |
| 34 | +1. Before submitting a PR, please ensure your changes have been tested on: |
| 35 | + - At least one Unreal Engine version between 4.11 and 4.25 (the version where UProperty was replaced by FProperty) |
| 36 | + - At least one version after 4.25, preferably UE 5.1 or newer |
| 37 | + |
| 38 | +2. All PRs must include: |
| 39 | + - A clear description of the changes |
| 40 | + - Steps to reproduce the issue being fixed (if applicable) |
| 41 | + - Code to reproduce the problem it fixes or feature it adds |
| 42 | + - Any relevant test cases or examples |
| 43 | + - Updates to the [Changelog.md](/assets/Changelog.md) file with relevant changes |
| 44 | + |
| 45 | +3. Code should be well-documented and follow the existing style conventions of the repository. |
| 46 | + |
| 47 | +## Development Workflow |
| 48 | + |
| 49 | +1. Fork the repository |
| 50 | +2. Create a new branch for your feature or bug fix |
| 51 | +3. Implement your changes |
| 52 | +4. Run the appropriate tests for your changes |
| 53 | +5. Update the documentation if necessary |
| 54 | +6. Submit a pull request |
| 55 | + |
| 56 | +## Code Style Guidelines |
| 57 | + |
| 58 | +### UEPseudo Code |
| 59 | + |
| 60 | +- Code in UEPseudo should match Unreal Engine's formatting and style conventions |
| 61 | +- When implementing code directly from Unreal Engine, maintain the original style |
| 62 | +- Any deviations or fixes from the original UE code should be enclosed between these comments: |
| 63 | + ```cpp |
| 64 | + // RE-UE4SS FIX (Contributor initials or username): [explanation of why the fix is needed] |
| 65 | + // Modified code goes here |
| 66 | + // RE-UE4SS FIX END |
| 67 | + ``` |
| 68 | + |
| 69 | + |
| 70 | +### Main Repository Code |
| 71 | + |
| 72 | +- All code in the main repository should have `clang-format` run against it before submission |
| 73 | +- Follow the existing code style of the repository for consistency |
| 74 | +- Use meaningful variable and function names |
| 75 | +- Include comments for complex logic or non-obvious implementations |
| 76 | + |
| 77 | +## Commit Message Guidelines |
| 78 | + |
| 79 | +- We favor [Conventional Commits](https://www.conventionalcommits.org/) format for all commit messages. |
| 80 | + ``` |
| 81 | + <type>[optional scope]: <description> |
| 82 | + |
| 83 | + [optional body] |
| 84 | + |
| 85 | + [optional footer(s)] |
| 86 | + ``` |
| 87 | +- Common types include: feat, fix, docs, style, refactor, test, chore |
| 88 | +- Reference issue numbers in your commit messages when applicable |
| 89 | +- Keep commits focused on a single logical change |
| 90 | + |
| 91 | +## Upgrade Guidelines |
| 92 | + |
| 93 | +We maintain an upgrade guide to track breaking changes and help users migrate between versions. |
| 94 | + |
| 95 | +### For Contributors |
| 96 | + |
| 97 | +When making breaking changes to the API: |
| 98 | + |
| 99 | +1. You must document all breaking changes in `/docs/upgrade-guide.md`, including: |
| 100 | + - A clear description of what changed |
| 101 | + - The reason for the change |
| 102 | + - Code examples showing the old way vs. the new way |
| 103 | + - Any special migration steps |
| 104 | + |
| 105 | +2. Breaking changes should follow these principles: |
| 106 | + - Minimize the impact on existing code |
| 107 | + - Provide deprecation warnings where possible before removal |
| 108 | + - Consider backward compatibility or transitional APIs |
| 109 | + - Clearly communicate the change through version numbering (follow semver) |
| 110 | + |
| 111 | +3. When submitting a PR with breaking changes: |
| 112 | + - Explicitly tag it with `breaking-change` in the PR title |
| 113 | + - Update the Changelog with a "Breaking Changes" subsection |
| 114 | + - Reference the PR in the upgrade guide |
| 115 | + |
| 116 | +### For API Users |
| 117 | + |
| 118 | +- The `/docs/upgrade-guide.md` file contains version-by-version migration instructions |
| 119 | +- Each major and minor version has its own section detailing changes |
| 120 | +- Always review the upgrade guide before updating to a new version |
| 121 | +- The guide includes code examples for adapting to API changes |
| 122 | + |
| 123 | +The upgrade guide is organized chronologically with the most recent version at the top, making it easy to follow incremental upgrades. |
| 124 | + |
| 125 | +## License |
| 126 | + |
| 127 | +### RE-UE4SS License |
| 128 | +By contributing to RE-UE4SS, you agree that your contributions will be licensed under the [MIT licence](https://github.com/UE4SS-RE/RE-UE4SS/blob/main/LICENSE) |
| 129 | + |
| 130 | +### UEPseudo Code Licensing |
| 131 | +UEPseudo code is subject to Epic Games' licensing terms. |
| 132 | + |
| 133 | +Thank you for helping improve RE-UE4SS! |
| 134 | + |
| 135 | +## Attribution |
| 136 | +This guide is based on the [contributing.md](https://contributing.md/generator)! |
0 commit comments