|[eclipse.org-planning-council] How Orbit dependencies should be managed in the future?|
Hi,During the call yesterday another point discussed was: "How Orbit dependencies should be managed in the future?"
The purpose of this thread is to launch the discussion about what we could do to prevent the integration problems we encountered recently in Neon.3 and Oxygen? I expect that we could provide some rules/best practices/process/tools to help the projects to integrate the release train.
Many different solutions were proposed on the mailing lists, a first step would be to get your opinion about all these solutions and see what could emerge. Following I list again the different solutions, feel free to comment them.
A. Be sure of the Orbit milestones. B. Check that 3rd party libs for SimRel come from Orbit. C. A tool to check consistency a kind of “SimRel consistency check”.D. The individual projects should not be allowed to contribute Orbit bundles to SimRel.
E. Don't include Orbit bundles in project's features.F. Communication/synchronization effort is necessary to harmonize versions across feature.xml of all participating projects.
G. Have an integration test suite that SimRel projects can contribute their own test bundles to and that runs against the finished packages.
These integration tests should cover basic user stories.H. Requiring projects on the train to have proper package uses constraints for all their bundles.
Thanks for your feedback, -- Mélanie Bats Eclipse Modeling Consultant +33 5 34 57 16 29 @melaniebats *Obeo* 25 Boulevard Victor Hugo - Colomiers - France http://www.obeo.fr
Back to the top