This document describes the comprehensive release process for OpenDAL, covering version management, automated workflows, and distribution of artifacts across multiple programming language bindings. The process encompasses the core Rust library and all language bindings including Java, Node.js, Python, C, and others.
For information about building and testing during development, see Building and Testing. For details about the CI/CD pipeline infrastructure, see CI/CD Pipeline.
OpenDAL follows a coordinated release strategy where the core Rust library drives version numbers, and language bindings may have independent release cadences based on their specific needs. The release process is heavily automated through GitHub Actions and involves multiple artifact types and distribution channels.
Sources: CHANGELOG.md1-379 bindings/java/pom.xml35 bindings/nodejs/package.json4
OpenDAL uses semantic versioning with coordinated releases across components. The version progression follows a predictable pattern with major, minor, and patch releases.
Sources: CHANGELOG.md10-379 bindings/java/pom.xml35 bindings/nodejs/package.json4 core/src/docs/upgrade.md1-761
The Java binding release process is the most complex, involving cross-platform compilation and Apache Nexus staging for release candidates.
Sources: .github/workflows/release_java.yml38-188 bindings/java/tools/build.py26-104 bindings/java/pom.xml249-273
The Java release workflow is triggered by specific conditions:
| Trigger Type | Condition | Purpose |
|---|---|---|
| Tag Push | v[0-9]+.[0-9]+.[0-9]+-rc.[0-9]+ | Release candidate staging |
| Pull Request | Changes to workflow or build files | Testing |
| Manual | workflow_dispatch | Ad-hoc releases |
Sources: .github/workflows/release_java.yml20-32
The Node.js binding uses a different approach with platform-specific npm packages and N-API for native integration.
Sources: bindings/nodejs/package.json11-25 bindings/nodejs/npm/darwin-x64/package.json1-20 bindings/nodejs/npm/linux-x64-gnu/package.json1-23 bindings/nodejs/npm/win32-x64-msvc/package.json1-19
The release process coordinates builds across multiple platforms and architectures, ensuring consistent artifacts for all supported targets.
Sources: bindings/java/tools/build.py26-47
Different language bindings use different distribution mechanisms optimized for their respective ecosystems.
| Language | Registry | Package Format | Authentication |
|---|---|---|---|
| Rust | crates.io | .crate | API token |
| Java | Maven Central | .jar, .pom | GPG signing |
| Node.js | npm registry | .tgz | npm token |
| Python | PyPI | .whl, .tar.gz | PyPI token |
| C | GitHub Releases | Source + headers | GitHub token |
The Java binding uses a sophisticated staging process through Apache Nexus:
Sources: .github/workflows/release_java.yml165-187
Language bindings implement sophisticated environment detection to load the correct native libraries at runtime.
Sources: bindings/java/src/main/java/org/apache/opendal/Environment.java47-63 bindings/java/src/main/java/org/apache/opendal/NativeObject.java55-76
The release process includes multiple quality gates to ensure artifact integrity and compatibility.
Sources: .github/workflows/test_fuzz.yml38-67 .github/actions/fuzz_test/action.yaml31-49
This comprehensive release process ensures that OpenDAL maintains high quality across all supported platforms and language bindings while providing a smooth upgrade experience for users.
Auto-refresh not enabled yet