When the development of a connector is finished, the release process can start. The release process will take place for both the initial and subsequent releases, however certain steps might differ slightly. The release process will make sure that the connector reflects the standards set in the Connector & App framework. In this process the following steps need to happen to create a release :
- Apply the appropriate versioning.
- Execute a review/validation on the connector.
- Create release notes.
- Create the release.
Semantic versioning is used to keep track of the different versions of connectors and apps. Version numbers are indicated by X.Y.Z and are updated according to the following guidelines:
- Z is updated for bug fixes that have no impact on the data model.
- Y is updated for new functionality that is compatible with the data model.
- X is updated when changes break compatibility with the data model.
Significant milestones of apps and connectors result in a new release.
A connector outputs data that corresponds to the data model of an app. The major version number of a connector is used to indicate which major version of the app it is compatible with. For example,
sample-connector 1.2.3 would be compatible with
sample-app 1.x.x, where
x can be any number.
Apps are versioned by taking into account the data model. The following examples describe how the version number should be updated:
- The metric
total_ordered_valuewas changed to use the field
- Update Z: App 1.0.0 → App 1.0.1
- The user entity is added to the app. The app has new content based on the newly added user entity. Having data for the user entity is not mandatory to use the app.
- Update Y: App 1.0.1 → App 1.1.0
- An update to the data model splits the
requisition_items. This means all current 1.x.x connectors would be incompatible with the new app.
- Update X: App 1.1.0 → App 2.0.0
Connectors 1.x.x are only compatible with App 1.x.x, which are all apps with major version 1. Connectors 1.x.x are not compatible with App 2.x.x, because a breaking change was introduced in the app. It is not possible that a connector has a higher major number than the corresponding app.
The following examples describe how the version number should be updated:
ordered_valuefield was based on the data source field for
requested_value. A fix is made such that the correct data source field is now used in the connector.
- Update Z: Connector 1.0.0 → Connector 1.0.1
- The connector now also outputs the user entity data, such that newly available dashboards in the app can be used. This was not a mandatory entity.
- Update Y: Connector 1.0.1 → Connector 1.1.0
- The requisitions table is split into
requisition_itemsto match the new data model of App 2.0.0
- Update X: Connector 1.1.0 → Connector 2.0.0
When a connector is ready to be validated, the content should be merged in the validation branch by means of a pull-request (PR). This PR can only be merged when the deliverables check is successful, which checks whether the required content is present.
When development of the connector is done, and the connector has the appropriate version number, the connector is submitted for review to UiPath. All deliverables will be validated to make sure they are complete and functioning properly.
The connector itself is delivered in a repository provided to you by UiPath. The repository structure is the same as described in Deliverables. Make sure all deliverables meet their required specifications.
After the validation is successfully completed, release notes can be created or finalized. For the initial release of a connector, the release notes will contain a general description of the scope of the connector. Release notes for subsequent releases need to contain the changes made with respect to the previous version.
When all previous steps are successfully completed, a release tag can be made of the connector in Git. See the GitHub Docs on Managing releases in a repository on how to create a release tag.
Updated 28 days ago