Adapter Change Management

Change Management

(these rules also apply for engine tickets alike, thank you!)

Change Request (Bugfix/Feature/Improvement)

For all kinds of change requests, please follow the Guideline For Change Requests

Pull Request

IN ADDITION to the issue you just created, you also have to option to deliver a proposed solution to the problem.
To do this, please follow through the 6 Steps To A Pull Request.
Additionally, in this case it is usually also a good idea to familiarize yourself with the CVS Conventions

Change Delivery

The delivery of changes happens through the release of a RC or a patch release. The change of a given issue does not automatically become available to the app dev when a issue is being set to resolved. In order to for a change to become available to the app for testing, it will need to be released.

The delivery of changes is slightly different depending on whether the affected version is an unreleased version (RC) or an already released version.

  • If the affected version is a release, the delivery of the change will be in the form of a patch release.
  • If the affected version is a RC, the delivery of the change will be in the form of a release candidate (RC).

Usually the adapter maintainer will create releases/RC’s on a rolling basis. Please check the respective release history whether the required change has already been delivered in a release/RC. If thats not the case, see “Release Request” below. New releases and RCs are also being announced in #adapter.

Release Request

A Release candidate (RC) is never allowed to be used in the release of an app/adapter. RCs are for testing and internal use only. In case a change or a set of changes are available in a RC, please request a release of a specific RC that has passed the app’s testing stages successfully. In case of a change being already available in a release, nothing needs to be done. The release can be used.

Release History