You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

Meaning of backward compatibility

  1. Major version backward compatibility: can 9.0.0 ACM-runtime has to be backward compatible with 8.0.0? How many version? can ACM-runtime 9.0.0 has to be backward compatible with ACM-runtime 7.0.0?
  2. Minor version backward compatibility:  as example, any 8.x.0 ACM-runtime has to be backward compatible with all ACM-runtime 8.y.0 versions.
  3. Decouple between ACM-runtime and intermediary library: ACM-runtime 8.x.0 version has to be backward compatible with all intermediary library 8.y.0 versions.

What impacts backward compatibility?

  • Rest Api call
  • Messages between ACM-runtime and intermediary library
  • interfaces AutomationCompositionElementListener and ParticipantIntermediaryApi
  • properties file of ACM-runtime and Participant

What could help the backward compatibility?

  • ability to handle multi major versions by Rest Api: high expensive to develop and maintain, also it will increasing the footprint.
  • abstract classes to help the implementation of AutomationCompositionElementListener. It will avoid to break existing code when new intermediary library version is released.

What the current integration does? it tests ACM-runtime and intermediary library of last version with the following flows:

  • Composition Definition: create, prime, deprime and delete
  • AC instance: create, deploy, undeploy and delete




  • No labels