|
1 | 1 | # Contributing to SwiftSQL |
2 | 2 |
|
3 | | -Thanks for your interest in contributing to SwiftSQL. |
| 3 | +SwiftSQL is intentionally small, explicit, and conservative. Thanks for keeping it that way. |
4 | 4 |
|
5 | | -SwiftSQL is intentionally small, explicit, and conservative by design. |
6 | | -Contributions are welcome, but only when they align with the project’s core goals. |
| 5 | +## Local build and tests |
7 | 6 |
|
8 | | ---- |
9 | | - |
10 | | -## Project goals |
11 | | - |
12 | | -SwiftSQL exists to provide: |
13 | | - |
14 | | -- A lightweight async ORM for plugin environments |
15 | | -- Explicit database access (no hidden magic) |
16 | | -- Stateless, thread-safe operation |
17 | | -- Compatibility with externally managed IDbConnection instances |
18 | | -- Predictable behavior under concurrency (Task.WhenAll) |
19 | | - |
20 | | -If a change pushes the project toward a full framework ORM, it will likely be rejected. |
21 | | - |
22 | | ---- |
23 | | - |
24 | | -## Non-goals (important) |
25 | | - |
26 | | -SwiftSQL does NOT aim to support: |
27 | | - |
28 | | -- Change tracking |
29 | | -- DbContext-style lifetimes |
30 | | -- Navigation properties or automatic joins |
31 | | -- Automatic schema diffing or repair |
32 | | -- Complex LINQ providers |
33 | | -- JSON-path querying |
34 | | -- ORM-managed aggregates |
35 | | - |
36 | | -Please do not propose features in these areas. |
37 | | - |
38 | | ---- |
39 | | - |
40 | | -## What contributions are welcome |
41 | | - |
42 | | -- Bug fixes |
43 | | -- Performance improvements |
44 | | -- Dialect correctness fixes |
45 | | -- Test coverage improvements |
46 | | -- Documentation improvements |
47 | | -- Small, explicit features that fit the existing design (for example: JSON column support) |
48 | | - |
49 | | -When in doubt, open an issue before writing a large change. |
50 | | - |
51 | | ---- |
52 | | - |
53 | | -## Code guidelines |
54 | | - |
55 | | -- Target framework: net10.0 |
56 | | -- Async-only APIs |
57 | | -- No global mutable state |
58 | | -- No connection ownership inside the ORM |
59 | | -- Prefer explicit behavior over convenience |
60 | | -- Keep public API surface minimal and intentional |
61 | | - |
62 | | -All new behavior should be covered by tests. |
63 | | - |
64 | | ---- |
65 | | - |
66 | | -## Tests |
67 | | - |
68 | | -- Tests live in `SwiftSQL.Tests` |
69 | | -- SQLite is sufficient for most tests |
70 | | -- New features must include tests |
71 | | -- All tests must pass before a PR is considered |
| 7 | +``` |
| 8 | +dotnet build |
| 9 | +dotnet run -c Release --project SwiftSQL.Tests/SwiftSQL.Tests.csproj |
| 10 | +``` |
72 | 11 |
|
73 | | -Run locally with: |
| 12 | +## Coding style |
74 | 13 |
|
75 | | -dotnet build |
76 | | -dotnet run -c Release --project SwiftSQL.Tests |
| 14 | +- Clarity and predictability over cleverness |
| 15 | +- Keep async APIs async-only |
| 16 | +- Avoid shared mutable state |
| 17 | +- Keep the public API surface minimal and intentional |
77 | 18 |
|
78 | | ---- |
| 19 | +## Public API changes |
79 | 20 |
|
80 | | -## Pull requests |
| 21 | +- Breaking changes require discussion before a PR |
| 22 | +- If behavior must change, document the impact and migration path |
81 | 23 |
|
82 | | -- Keep PRs focused and small |
83 | | -- Avoid refactors unrelated to the change |
84 | | -- Explain why the change is needed, not just what it does |
85 | | -- Breaking changes require discussion first |
| 24 | +## Issues and pull requests |
86 | 25 |
|
87 | | ---- |
| 26 | +- File issues with clear steps or a minimal repro |
| 27 | +- Keep PRs focused and explain why the change is needed |
| 28 | +- Avoid unrelated refactors |
88 | 29 |
|
89 | | -## License |
| 30 | +## Branching |
90 | 31 |
|
91 | | -By contributing, you agree that your contributions are licensed under the same license as the project (MIT). |
| 32 | +- main is stable and release-ready |
| 33 | +- Features and fixes land via PRs |
92 | 34 |
|
93 | | ---- |
| 35 | +## Testing expectations |
94 | 36 |
|
95 | | -Thanks for helping keep SwiftSQL simple, predictable, and boring (in the best possible way). |
| 37 | +- New code must include tests |
| 38 | +- All tests must pass before review |
0 commit comments