Common Adapter Documentation/Release Process

Adapter Release Process

The adapter release process is tightly coupled to the pEpEngine release process. A normative documentation for both can be found here.

Additional Scenarios

Whenever i experience a scenario that requires further clarification, i discuss with the peers (e.g. Engine / Apps) and manifest the conclusions and agreements here.

Procedure for public releases

This is a very short summary of the release process.

  • app asks for a release
  • engine/adapter make a release (tag only)
  • app makes public release

Procedure for bugfix releases for public releases

— ATTENTION: STOP READING - DRAFT STATE - BEGIN —

  • create a mainetenance branch from the release tag (e.g. Release_2.1.0)
  • Work towards the patch release with increasing RC numbers - Release_2.1.1-RC1, Release_2.1.1-RC2, Release_2.1.1-RC3 and so on.
  • Tag the final revision with the public patch release identifier (e.g. Release_2.1.1)
  • This patch can be used by the app in their public release (all changes made on a bugfix branch will be applied to default branch/head)

Procedure for bugfix releases for test releases

We have the scenario that the app has an RC in testing that might end up in a public release. At the same time, development on default branch must continue.

If there is a code change needed on a RC used in a test release:

  • create a branch from this RC
  • implement bugfix on this branch
  • the new commit will get an RC tag with inceremented patch number
  • The app will need to ask for a release (rel tag) before allowed to release (all changes made on a bugfix branch will be applied to default branch/head)

(as discussed and agreed with huss)

— ATTENTION: STOP READING - DRAFT STATE - END —

pEp internal release process

API changes

API changes, like any other changes are made available to the adapter users with a normal RC, but they must be in coordination with the app.

Public Release

The adapter/engine can not make a public release on their own. A release always gets initiated by the app making a release themselves. But the apps are not allowed to use anything but a public release of engine/adapter. They have to request a release of engine/adapter, because unless they request one, there is none.

The reason engine/adapter can not make public releases themselves is, that in order for an RC to get released it needs to complete testing phase, and testing is being done on app level. Thats why the app initiates a release always, never the engine/adapter.

Release Candidated (RCs)

Basically the main reason the RCs got introduced is, that the dev is now free to use fine grained commits that are by no means complete nor do they have to compile or anything, because the apps are only allowed to use RCs. then, then another reason why they arent Releases, but just RCs is, that the app is not allowed to use RC’s in public releases, that way the engine/adapter knows for sure what has been publicly released, and can try to make the apps use the same release for a major public pEp release, where all apps have a release for the same high level requirements.