Suggested splitting of crates

[geofmureithi]

Before this crate reaches v1.0, I am suggesting we split the crates into different repos.
Here is how the structure would look like:

1. apalis layers and apalis core, remain on this repo
2. Backends like apalis-redis, apalis-postgres, apalis-cron etc would be moved into their own repos.
3. Other backends such as diesel, rsmq, surrealdb and natstream would also be introduced in their own repos too.

What is the motivation behind this?

• Allow better documentation
• Allow more complex testing and benchmarking
• Allow more focused discussions on the direction.

That said, there will stiil be generic tests that every backend will need to pass to be considered stable.
Any thoughts and questions are welcome!

[geofmureithi]

Here is the suggested checklist for the crates:

Apalis Libraries Stability Checklist

📦 Project Setup

• Cargo Manifest (Cargo.toml)
  • Correct name, version, description, license, repository, and homepage fields.
  • Appropriate edition (e.g., 2021).
  • categories and keywords for discoverability on crates.io.
  • readme file specified.
  • license field correctly set.
  • Ensure [dependencies] are minimal and stable.
  • Mark unnecessary dependencies as optional.
  • Use features to enable optional functionality.

🛠 Code Quality & Conventions

• Code is idiomatic and follows Rust best practices.
• Uses rustfmt for formatting (cargo fmt).
• Linted with clippy (cargo clippy --all-targets --all-features).
• Minimal and clear public API.
• Stable and well-defined API with #[non_exhaustive] where necessary.
• No unnecessary unsafe code (#![forbid(unsafe_code)] if possible).
• Comprehensive documentation (cargo doc).
• Public items have doc comments (///).
• Examples provided in documentation where useful.

🧪 Testing & Code Coverage

• Unit tests for all core functionality (cargo test).
• Integration tests for key use cases (tests/ folder).
• Documentation tests (cargo test --doc).
• Property-based tests (e.g., with proptest).
• Test with miri to check for undefined behavior (cargo miri test).
• Test coverage reporting (e.g., grcov).
• Ensure CI runs all tests on multiple platforms (Linux, macOS, Windows).

🔄 Continuous Integration & Automation

• GitHub Actions (or another CI) setup to run:
  • cargo fmt -- --check
  • cargo clippy --all-targets --all-features -- -D warnings
  • cargo test --all-features
  • cargo doc --no-deps
  • Test matrix (stable, beta, nightly, MSRV, multiple platforms).
• Check for outdated dependencies (cargo outdated).
• Ensure dependencies have minimal versions (cargo minimal-versions).
• Security audit with cargo audit.
• Benchmark performance if needed (criterion).

📦 Crates.io Release Readiness

• Ensure README.md is informative and up-to-date.
• Ensure CHANGELOG.md exists and follows keepachangelog format.
• LICENSE file is present.
• Release process automated (cargo-release or cargo publish --dry-run).
• Ensure rust-version is set in Cargo.toml.
• Check that include and exclude fields are correctly set to minimize crate size.

🏛 Stability & Maintenance

• Follow semantic versioning (semver).
• Deprecate old APIs properly instead of breaking changes.
• Ensure MSRV (Minimum Supported Rust Version) is documented.
• Monitor issues and respond to community feedback.
• Have at least one co-maintainer or documented bus factor mitigation plan.
• Consider setting up rustsec advisory for vulnerabilities.

🌍 Ecosystem & Adoption

• Ensure the crate integrates well with the Rust ecosystem.
• Provide examples (examples/ directory).
• Write a guide or blog post for users if applicable.
• Announce stable releases on relevant channels (Reddit, Twitter, Discord).
• Encourage contributions with a CONTRIBUTING.md.

---

Following this checklist will help ensure your Rust library is stable, well-maintained, and user-friendly. 🚀

[anthonykimani]

@geofmureithi In full support, should we will have github issues for the checklist to cross against it.