GitHub user Xuanwo edited a discussion: proposal: Release OpenDAL Components Seperately
# Summary Release OpenDAL Components Seperately with different version for each component. # Motivation OpenDAL has a lot components like - bindings: c, cpp, java, python, nodejs, ... - applications: ofs, oay, oli - integrations: object_store, dav-server They are at different stages of development. The bindings for `java`, `python`, and `nodejs` have reached a level of maturity where they can be released with the `core` for every version update. However, most of them are still in development and do not have regular releases. I believe they cannot reach maturity until we expose them to users and gather feedback. We should release them separately from the `core`, assigning most of them a version number like `0.1.0` or even `0.0.1`. In addition, mature components encounter their own issues. Bindings such as `java`, `python`, and `nodejs` require a minor version update for each change in the opendal core. It is important to remember that in the semver world, this constitutes a breaking change for version `0.x`. We must discover a method to enable bindings like java and python to maintain their own versions so that users can make informed choices. # Proposal So I propose to release opendal components seperately with different version for each component. Instead of a single large release of `apache-opendal`, we will be releasing `apache-opendal-core`, `apache-opendal-binding-python`, and `apache-opendal-bin-oli` separately. This allows users to build and verify each component individually, without needing to refer to `../../core` or similar paths. Each component will have its own version with embedded build metadata. For example, under the tag `0.50.0`, we will have: - `apache-opendal-core-0.50.0` - `apache-opendal-binding-python-0.46.0+core.0.50.0`: python binding depends on core v0.50.0 - `apache-opendal-bin-ofs-0.0.1-core.0.50.0`: app ofs depends on core v0.50.0 - `apache-opendal-binding-go-0.0.1+binding.c.0.50.0`: binding go depends on c binbding v0.50.0 If there are no API changes in the Python binding, we can keep its version unchanged and only update the build metadata of the core to a new version. For languages like Node.js that do not consider build metadata for version resolution, we can simply increment the patch version instead. The entire release workflow remains unchanged. We still release Apache OpenDAL as a whole. The difference is that during the release discussion, we need all code owners of the components to decide which version to use in their respective component. The Release Manager is responsible for updating them accordingly. We will modify `release.sh` to generate all the tarballs with the correct version. Additionally, we will include a release note for each component version along with their corresponding change logs. # Drawbacks ## Tag on repo is not the same with component version After this change, the tag on the repository is for the entire Apache OpenDAL project instead of just a component. It's possible that the Python binding has version 0.46.0, but the repository has a tag v0.50. # Rationale and alternatives ## Don't change release style We can maintain our current processes without making any changes. ## Release every component seperately We have over 10 components, but our community is not prepared for releasing them individually. That means we need to set up the release process for each component and vote on them individually, which is not interesting. ## Split opendal monorepo into different repos A monorepo is beneficial for development as it allows for increased visibility. Having separate repositories makes it more challenging for maintainers to track and involves tedious setup work, such as tests. # Prior art None # Unresolved questions None # Future possibilities None GitHub link: https://github.com/apache/opendal/discussions/4126 ---- This is an automatically sent email for [email protected]. To unsubscribe, please send an email to: [email protected]
