Breaking changes

Support
1

Hi,

We do not update EasyMorph that frequently because it impacts several users.
It is not so easy to assess the impact of breaking changes when there have been several releases since our current version.

  • Is it possible to make a central table of breaking changes (not in the PDFs) and indicate if the breaking change requires manual intervention ? Is it possible to always provide a morph project for each breaking change so that we can easily find all impacted morph files ?

  • I have noticed that the concatenate action replaced the aggregate action with concatenate option. Does this have impact on existing flows ? I have noticed that in 1 morph file the action was disabled but after upgrade, the action is enabled.

image

In the morph file (XML, it says it is disabled). So that’s weird.

image
image1331×669 32.9 KB

2

Breaking changes are described in the Release Notes because that's where most customers expect them to be. A change is classified as breaking if it may or will require user action. Changes that don't require user action are not considered breaking. When there is a breaking change, we usually describe its nature and suggest actions to mitigate it.

I confirm it's a bug on our end (rather than a breaking change). A disabled action should not become enabled during project migration to a newer version. We will fix it as soon as possible.

To reduce the risk of updating to a newer version, I would suggest requesting a trial license and testing new versions before updating.

3

The bug has been fixed. The updated version is available on our website.

1 Like