Engine Version

  • Traceability - Engine version compiled in at runtime using a generated VERSION file containing hash and tag of the
  • VERSION file should be generated right before the build in the “Makefiles”
  • Compile the version into the binary as a symbol in the DS (Data Segment)


current versioning number format: <major>.<minor>.<patch>
Currently we derive the engine version from the adapter version. Major and minor number have to be the same. The independent part is the patch number.
API breaking changes and DDL changes are only allowed between major releases.
These rules result in the following problem: The adapter can not do an API change without the engine doing a major release. But this flexibility is required.

Volkers current suggestion is to use 2 different version numbers for 1 adapter (binary release)
* DDL Version (Engine) * API Version (Adapter)

We need to clarify and make decisions on this topic.

New Release docs

  • https://dev.pep.foundation/pEpJNIAdapter/releases
  • https://dev.pep.foundation/pEpPythonAdapter/releases
  • https://dev.pep.foundation/libpEpAdapter/releases

  • Is there anything like this for the engine (rel doc containing deps and changelog)?
  • The source of version information for the Engine is the DEPENDENCIES file.

git workflow

  • start using squash commits for merging in feature branches
  • Generate changelogs from the master branch gitlog

Version branching

  • when do we switch to 2.2 branch what is the definition for to decide
    whether code is supposed be released into 2.1.patch-rel, or into 2.2-RC ?