Contributing

Build, test, and change Zinc

Start with the roadmap and design rationale. Keep a change focused on a bug or feature with a clear behavioral outcome.

Build and check

From a repository checkout:

cargo build --release -p zinc-core --lib --example interop --locked
cargo fmt --all -- --check
cargo test --workspace --all-targets --locked
cargo clippy --workspace --all-targets --all-features --locked -- -D warnings

Install the adapter runtimes you need, then run bash tests/runner.sh. Python needs python3 -m pip install -e 'adapters/python[test]'. The Node package has its own Cargo manifest and checks. The development guide describes the layout, dependencies, and benchmark limits.

Changes to the core

Mapping operations live in core/src/platform/unix.rs. MappedFile unmaps on drop and file descriptors close after mapping. Notification behavior lives in core/src/sync.rs. Preserve the timeout and memory-ordering contracts on both supported platforms.

Add regression tests for behavioral fixes. Check failed setup, creator-first close, pending notifications, and capacity boundaries when they apply. Keep hot data-access paths free of allocations and preserve the C ABI layout.

Edit Rust declarations or core/cbindgen.toml to change the C header, then regenerate it:

cargo run -p zinc-core --example generate_header --features generate-header --locked

Ordinary builds use the checked-in header and skip cbindgen. Add -- --check to verify it without writing; CI and release builds check this too. Do not edit include/zinc.h directly. Update adapter declarations when adding an exported function.

New adapters

Wrap the C ABI in native types, translate errors, and define the lifetime of returned views. Test against the built library and fail when it cannot load. A blocking wait needs a separate thread or process if the producer runs asynchronously in the same runtime.

Include setup instructions, data-sharing tests, notification tests, and close behavior. Run tests with the actual system page size or a capacity aligned to it.

Review and releases

Describe the behavior changed and how it was checked. Update affected docs and roadmap entries. Use short commit messages consistent with the repository history.

The tag workflow builds Linux and macOS shared libraries and attaches them with the C and C++ headers to a GitHub release. Registry publishing for language packages is still pending; tagging does not publish those packages.