[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[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
