|
| 1 | +### Project Scope & Philosophy |
| 2 | + |
| 3 | +Egor is a **graphics engine**, not a game engine |
| 4 | + |
| 5 | +Changes must: |
| 6 | + |
| 7 | +- Be broadly applicable to **apps, tools, and games** |
| 8 | +- Avoid assumptions about game-specific concepts (entities, scenes, physics, AI, etc.) |
| 9 | +- Keep APIs generic and composable |
| 10 | + |
| 11 | +If a change only makes sense for games, it likely does not belong in egor |
| 12 | + |
| 13 | +### Commit Messages |
| 14 | + |
| 15 | +Egor uses [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/). This helps `git-cliff` parse git history for generating clean release notes |
| 16 | + |
| 17 | +Format: |
| 18 | +type(scope): short description |
| 19 | + |
| 20 | +Examples: |
| 21 | + |
| 22 | +- fix(renderer): handle `begin_frame()` returning `None` |
| 23 | +- refactor(app): move window title into `AppConfig` |
| 24 | +- Avoid vague types/messages (e.g. `chore: stuff`, `fix: misc`) |
| 25 | +- docs(readme): clarify wasm setup |
| 26 | + |
| 27 | +Rules: |
| 28 | + |
| 29 | +- One logical change per commit |
| 30 | +- No unrelated commits in a single PR |
| 31 | +- Squash commits are preferred if history gets messy |
| 32 | + |
| 33 | +### Pull Requests |
| 34 | + |
| 35 | +Before opening a PR: |
| 36 | + |
| 37 | +- [ ] PR addresses **one** issue or feature |
| 38 | +- [ ] Commits are clean and logically separated |
| 39 | +- [ ] No unrelated refactors or formatting changes |
| 40 | +- [ ] Code builds on native **and** wasm (if applicable) |
| 41 | +- [ ] Public API changes are explained in the PR description |
| 42 | + |
| 43 | +Scope check: |
| 44 | + |
| 45 | +- Does this help **any 2D app**, or only a game? |
| 46 | +- Can this be implemented outside egor by the user? |
| 47 | +- Does this reduce flexibility or lock users into a pattern? |
| 48 | +- Would this make egor harder to use as a general-purpose graphics library? |
| 49 | + |
| 50 | +If unsure, open an issue or ask in [Discord](https://opensourceforce.net/discord) first |
| 51 | + |
| 52 | +Large or architectural changes should be discussed in an issue first |
| 53 | + |
| 54 | +PRs that mix unrelated changes may be closed or asked to split |
| 55 | + |
| 56 | +### Pre-PR Checklist |
| 57 | + |
| 58 | +Before submitting, make sure your changes pass these commands: |
| 59 | + |
| 60 | +```bash |
| 61 | +# Check formatting |
| 62 | +cargo fmt --all -- --check |
| 63 | + |
| 64 | +# Build and test native |
| 65 | +cargo test --all-targets --all-features --locked |
| 66 | + |
| 67 | +# Lint with Clippy |
| 68 | +cargo clippy --all-targets --all-features --locked -- -D warnings -A clippy::new-without-default |
| 69 | + |
| 70 | +# Verify documentation builds |
| 71 | +cargo doc --no-deps --document-private-items --locked |
| 72 | +``` |
0 commit comments