Contributing
Make a provider change reproducible, then verify its observable behavior.
Examples use Classic and Fluent tabs. Your choice follows you through the manual.
A useful report
Include package, database and driver versions, a minimal migration, relevant schema/data, and expected versus actual behavior. Remove secrets from connection strings and logs. File reports in the issue tracker.
A focused change
Add a regression that fails before the fix and checks the real result afterward. Provider-specific changes need actual-engine evidence; skipped tests and generated SQL alone do not qualify support. Keep mutable definition inputs independent from caller arrays and check failure paths.
Documentation changes
Edit docs/_src/content.py for chapters and docs/_src/home.html for the homepage. Run python .github/scripts/build-docs.py to regenerate static HTML and the search index. Run python .github/scripts/verify-docs.py --compile to validate links, paired examples and compilable C# samples. Site assets live in docs/assets.
Each migration-operation example should provide Classic and Fluent versions. Shared runner and shell commands intentionally appear in both tabs. Keep provider restrictions precise and features described in the present tense. Run the homepage CI-count renderer tests when changing the site template.
Design references
The chapter organization follows the learning path of FluentMigrator’s documentation, adapted to this API. Visual references include Resend’s typography and code tabs and Gel’s code walkthroughs. The site uses its own palette, layout, copy and migration illustrations.