Engine Branches and Releases

Development occurs in the default branch. Branches may occur during development (for example, the current engine convention is to create bug-fix and feature branches when, during development, the engine dev team wants to keep development separate); these are merged on a rolling basis upon completion of implementation and internal testing when not referring to major releases (e.g. API-breaking changes).

Additionally, we have feature branches, which are generally moved into default after completion and testing with the app teams.

Releases are handled as follows - minor and patch releases are tagged, and we branch upon major releases.

Major releases are done when incompatibilities occur, and a branch is created for the old version (so, for example, when there is an API change in decrypt_message, something which causes major impact on users of the engine). This process will begin after the release of 1.0.441 (done on 10 August 2018, and which should have been 423 to make Volker happy, but events ended up incrementing the number ;) ).

Bugfixes, etc, can then be backported to the supported older release branches.

Adapter Release Version

Adapters MUST use the same major/minor versions as the engine releases; however, they may be/remain older in the case of minor changes.

In general, there should be an adapter release when there is an engine release; this, as mentioned above, may not apply when the changes to the engine were minor and don’t really impact the adapter.