Engine/EngineBreakfast/Log_20210309

Change mgmt

Versioning

Hecks initial analysis

Problem:

  • The coupling of version numbers (major and minor) from engine to adapters is creating issues.
  • The concept of coupling versions numbers and semver semantics are contradicting each other.
  • We cant have both

Solutions heck can think of:

  1. define only engine is using semver, (remove all semantics from adapter/app versions)
  2. Use strict Semantic Versioning (https://semver.org/), decouple version numbers, and document DDL Version / Engine version in the release info of adapter. (Heck proposes)

Decision with fdik

  • Coupling is very important Engine/Adapter version nr.
  • We develop by contract / there can be exceptions to semver rules (major/minor/patch semantics) if all contract partners agree.

  • Engine: DDL change is new minor release -> heck: ? really?
  • engine/adapter/deployment versions are coupled by major and minor.
  • Patch numbers are independent from each other, respectively
  • libpEpAdapter and everything other than engine/adapter have totally independent version semantics.
    • Explicitly: for APPS, the version-nr has nothing to do with the engine version number (ever since)
  • pEpPythonAdapter setuptools_scm tag format (Release_x.x.x) currently not compatible
    • version tags has to stay the same, python adapter needs to adapt.

Git workflow

  • We should define and document the branching model and workflow for each sw-component.
    • fdik: that will need to be a concise, short and open specifications as possible
    • fdik: as little change as needed from current state
  • Unify across components as much as possible?
    • fdik: Only if it really makes strong sense
  • Heck proposes to think about declaring GitFlow as a starting point