Bugzilla – Full Text Bug Listing
| Summary: | Document the Sirius compatibility and migration policy | ||
|---|---|---|---|
| Product: | [Modeling] Sirius | Reporter: | Pierre-Charles David <pierre-charles.david> |
| Component: | Core | Assignee: | Pierre-Charles David <pierre-charles.david> |
| Status: | RESOLVED WONTFIX | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P3 | CC: | florian.barbin, laurent.redor, stephane.bonnet |
| Version: | unspecified | Keywords: | triaged |
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
|
Description
Pierre-Charles David
One thing currently missing from the document is which Eclipse versions we want to support. The main target is clearly Luna (4.4), but we currently have clients which are on Helios (3.6) and as part of Obeo Designer we mainly test on Eclipse 3.8. This means the code currently has to build and work on 6 versions of Eclipse: Helios (3.6), Indigo (3.7), "Juno 3" (3.8), Juno (4.2), Kepler (4.3) and Luna M3 (4.4). I don't believe this is sustainable (particularly in terms of testing) and propose that we concentrate on: - Eclipse 3.8, as the last of the 3.x, as we expect many users to stay on 3.x as long as they can to avoid the changes implied by moving to 4.x. - Kepler (4.3), at least until we ship Sirius 1.0, as this is the stable version early adoprters of Sirius milestones will most likely be using unless they fell very adventurous and try Luna milestones. - Luna (4.4) as our main target, as we are part of the train. This means we could abandon 3.6, 3.7 and 4.2 right now, and Kepler probably next year. I confirm Thales will not need Sirius on Eclipse 3.6. Our main target at this stage is Eclipse 3.8 The migration of Viewpoint models, representations files (.aird) and VSM (.odesign), and Modeling Projects to Sirius 0.9.0 are handled by https://bugs.eclipse.org/bugs/show_bug.cgi?id=422478. See this bugzilla for specific informations on this part. Moving to 3.0 to rework on this and publish a stable/finished version. In particular, one point the document should handle is users who may be worried to see the major version of Sirius moving so fast (2 to 3 major versions each year), which could imply that we break all our APIs all the time. We should make it clear that this is not the case and distinguish: * Sirius models (aird and odesign), for which we guarantee transparent upward migration "forever" (at least until further notice). * Core Sirius APIs, the ones most likely to be actually used by advanced modelers and downstream projects. For example I believe none of these was modified between 1.0 and 2.0, see for example Ecore Tools and UML Designer, which although they use some of our APIs work the same with 1.0 and 2.0. * Non-core Sirius APIs, mostly things made public by a Sirius bundle to be used by another Sirius bundle, and also some more advanced/obscure APIs. These are more likely to be broken between major versions, but: we try (or should try) to first deprecate an osbolete API for one major version before it is actually removed, and all changes are described in details in the release notes, with pointers to alternative/prefered APIs where appropriate. The two levels of APIs is currently mostly informal and defined "de facto" by "what is actually used in practice by the Sirius-based systems we are most aware of". Maybe we should think of a way to make this distinction clearer and base it on well thought and well defined criteria. Available in Sirius 3.0.0. See https://wiki.eclipse.org/Sirius/3.0.0. This was closed by mistake as part of the bulk operation on all the Sirius 3.0.0 tickets. It was planned for 3.0 but does not actually involve any code, only a wiki page. I'll try to get to this in the next few days/weeks, but this is actually independent of a specific release schedule. |