GitHub user Xuanwo edited a comment on the discussion: proposal: Release OpenDAL Components Seperately
> Fixing the core version for a binding version increases the burden for > downstream adopting We are not fixing the core version. The whole opendal project will release at the same time. For example, let see core release `v0.50.0` from `v0.49.0`: - If no API changes in python binding, they will release `v0.46.0+core.0.50.0` from `v0.46.0+core.0.49.0` - If some API changes in nodejs binding, they will release `v0.68.0+core.0.50.0` from `v0.67.0+core0.49.0`. The semver for components is determined by their owners based on their public API. > we omit the core version so that downstream users just pick against binding > version. In semver, the `+core.0.50.0` part is treated as `build metadata`. Languages interpret semantics differently. For instance, Rust considers them in semantic versioning calculations, while Node.js completely ignores them. We leave these decisions to the code owners based on their own API changes. > The point here is whether we make core package version associated to the > bindings' version a public interface and how we define its semantic. As mentioned before, after this change, core version are just `build metadata` and not part of binding's public API. The most important thing is that the OpenDAL project is always released as a whole at the same time, so there's no range of core versions to choose from. GitHub link: https://github.com/apache/opendal/discussions/4126#discussioncomment-8355377 ---- This is an automatically sent email for [email protected]. To unsubscribe, please send an email to: [email protected]
