Sirius/Compatibility and Migration

This page documents the compatiblity policy for Sirius releases, both for users of the Viewpoint technology (the previous name of Sirius) who want to switch to Sirius and from new adopters of Sirius itself.

Overview of the Sirius Releases Roadmap Until 1.0

Sirius is currently in incubation. The goal is to get get out of incubation status with a 1.0.0 release to be included in the Luna release train in June 2014. We will follow the Luna calendar and the corresponding milestones, starting from M4 (M3 has already passed). Before that we will do a first official release named 0.9.0 in the next few weeks (having at least one official release is a requirement of the Eclipse process to be allowed out of incubation).

The scope of this version 0.9.0 is to be as close as possible to the current version of the previous code base (Viewpoint), except for the "rebranding". This is to facilitate the migration of users who previously used Viewpoint to Sirius by providing a baseline version in which the only changes to be concerned about are related to the rebranding, with no new features or API changes. In practice there might be a few incompatible changes beyond just the rebranding but they will be very small and documented in the release notes for Sirius 0.9.0 (see the actual release notes document).

The 0.9.x branch will not be maintained, it is purely transitional. We may do 0.9.x maintenance releases if major issues are detected on the 0.9.0 release which prevent people to migrate to it with functionalities equivalent to what they add in Viewpoint, but bugs which already existed in Viewpoint will not be fixed in the 0.9.x branch. Even "normal" (i.e. neither blocker or major) bugs specific to Sirius 0.9.0 may not trigger a 0.9.x maintenance release by themselves. Note that according to the EDP, maintenance/service releases do not need the full paperwork of normal Eclipse releases, so the decision to not maintain 0.9 is purely so that we can focus our developement time solely on providing a high quality 1.0 release and not disperse the team on maintaining more branches.

Between 0.9.0 and 1.0.0, we will provide milestone releases synchronized with the Luna calendar. Again, milestone releases are not official Eclipse releases with paperwork associated. Milestone releases do not result in a separate branch, so they will not be maintained (i.e. no M4.x releases); any issue on a milestone will only be addressed on the master branch.

This gives is the following calendar:

• 2013-11-30: Sirius 0.9.0 released (more likely early December given the current state).
• 2013-12-20: Sirius 1.0.0M4 released with Luna M4.
• 2014-01-31: Sirius 1.0.0M5 released with Luna M5.
• 2014-03-14: Sirius 1.0.0M6 released with Luna M6.
• 2014-05-07: Sirius 1.0.0M7 released with Luna M7.
• 2014-06-25: Sirius 1.0.0 released with Luna.

Objective and General Rules

In general incompatible changes between two versions should be the exception and not the general rule. Any incompatible change should be clearly justified and its impacts minimized.

The rules:

1. whenever possible, allow seamless and transparent migration;
2. if that is not possible, provide automated or semi-automated tools to assist in the migration. These tools should be usable programmatically (no just by UI actions) to allow users with lots of existing data to automate the migration.
3. if automation is not possible or considered too costly, provide complete documentation of the manual steps to perform to migrate existing projects.

In all cases (even when the migration can be handled transparently), all changes should be clearly documented in the release notes of the release or milestone in which they appear first.

Types of Compatibility Issues

• VSM
• Representations Files
• Modeling Projects
• Plug-in dependencies
• Extension points and other ids
• Java namespaces
• Java APIs

Migration Paths

General Rules

• Stepwise migration: first to the latest version of Viewpoint available, then to Sirius 0.9.0, then each milestone in turn up to 1.0.0 final.
• For a given project, document in which order to migration the VSMs, APIs, aird etc.