imbajin commented on issue #3110: URL: https://github.com/apache/hugegraph/issues/3110#issuecomment-5083686686
Thank you very much for digging into this and for offering to take on the interoperability, build, test, and licensing foundations. The community very much welcomes your participation and these suggestions. A few updates and clarifications from our side: 1. The community is already working on reducing some of the historical compatibility and technology-stack burden in [#3117](https://github.com/apache/hugegraph/pull/3117). If that proceeds smoothly, we hope to move the project baseline to Java 17 soon. Without the current TinkerPop version constraint, Java 21 would also be feasible, but with the existing dependency relationship we will likely need to wait for TinkerPop 4.0. 2. `hugegraph-commons` no longer needs to remain Java 8 compatible and can move to Java 11. `hugegraph-client` is the only component where we may still need to consider older-Java compatibility; the other components do not have that requirement. 3. For the initial Rust work, supporting x86_64 and ARM/aarch64 is sufficient. We do not need to cover other architectures for now. On unsupported or incompatible environments, a graceful fallback to the existing Java implementation is the preferred direction. 4. The component priority is to start with Toolchain because it has the smallest dependency and compatibility surface, is relatively independent, and has clear potential benefits from a CLI-oriented implementation. This does not mean storage, server, or graph-computing exploration cannot proceed in parallel; those areas simply need more caution because of their compatibility and correctness impact. 5. We completely agree that the surrounding foundations and evaluation work can start now. Compatibility inventories, golden fixtures, test oracles, differential validation, the PoC selection matrix, and an interoperability draft would all be useful and can proceed in parallel. There is no need to wait before starting the testing and validation work. We would also be very happy to have contributors with deeper Rust experience join the design review and validation, so that the approach can be confirmed collectively and evolved incrementally and safely. Overall, this is a very useful and pragmatic proposal. Thank you again for the careful investigation and for volunteering to help build the foundations. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
