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

Compare with Current View Page History

« Previous Version 2 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 versions? 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 tests 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

Maybe it needs to add into the integration tests all new functionalities recently developed using participant-simulator.

About the regression tests, the only flows that could be tested will be based on what functionalities support the older version installed for the test.




  • No labels