EDAPT 1.3.0 released!

We are happy to announce that, we have released EDAPT 1.3.0!

We want to thank all committers and contributors for their work as well as all users and adopters for the feedback and support!

EDAPT is a framework to support the migration of model instances in case of a model change (in your Ecore model). If you are not yet familiar with EDAPT, please refer to this tutorial for an introduction.

The 1.3.0 release contains two remarkable new features, which ease your daily life when using EDAPT: A detector, when a migration is even necessary and a simplified “release dialog” (details in the following)

EDAPT allows you to create a history of changes that are applied to a model

Model in this context means the definition of your entities (.Ecore file). Based on this history, EDAPT is capable to almost fully automatically migrate instances of this model (i.e. the user data of your tool). Therefore, EDAPT organizes changes to the model in “model releases”.

Every release represents a state of your model definition. This state is defined by the predecessor release and all recorded changes to the model since then.

The following screenshot shows an example of such a history. As you can see, the second release is not yet marked as “released”, so EDAPT would not create any migrators for the model changes in this release, yet.

When considering migration, EMF provides the nice capability, that things, which get added to the model do not require migration by default. Therefore, there might be releases in your model history, which do not even require explicit migration by EDAPT. These releases only contain “non-breaking changes” then.

The information whether the current release contains breaking changes is valuable, because even when using EDAPT those releases need some more attention. As an example, you want to add some test cases to check, that the automatic migration works as expected. Further, you might want to skip an explicit model release, if it does not contain breaking changes anyway.

Finally, you might even avoid a breaking change in the model, e.g. if you only do a service release of your software, which should not migrate any model instances.

Therefore, the new EDAPT release calculates exactly this information, whether a release contains breaking changes upfront and displays it directly in the model history.

In the following screenshot, another change was added to the history. This change renames a Class and is therefore “breaking”. As a result, the containing release is marked in red and shows that it contains breaking changes.

The second improvement affects the process of creating a model release

When doing a release, the URI of all models which are affected by a breaking model change has to be updated. This is necessary, so that a tool knows the model version before de-serializing a file. Typically, you append a version number to the URI and increase this on every new (incompatible release).

In previous versions of EDAPT, this process was quite some work, especially if your model is split in many sub models. More specifically, you had to make the decision, whether to update the URI for a specific sub model. Further you had to click through every single sub model, even if it was not changed at all. In version 1.15.0, there is a improved dialog for updating the model URIs. It displays all affected models at once.

Further, it automatically suggest the sub models to be updated (based on whether they contain breaking changes).

The two features plus other improvements are available starting from release 1.3.0. You can download and install them from the update site (1.3.0 or higher). If you miss any other feature in EDAPT or ways to adapt it, please provide feedback by submitting bugs or feature requests or contact us if you are interested in enhancements or support.