Rules for the Semantic Version Check

When you push an adapter to Oracle Integration, Oracle runs a semantic version check. This check determines whether your changes are maintaining backward compatibility and provides guidance for updating the version number of the adapter.

Note:

Currently, the Rapid Adapter Builder doesn't allow a major version change.

About Semantic Versioning

Oracle enforces semantic versioning rules, also known as SemVer, for all adapters built using the Rapid Adapter Builder.

With semantic versioning, you increment your version numbers in a meaningful and controlled way. When users know that your adapter uses semantic versioning, they understand that the version number provides a quick explanation of the types of changes that are in the version.

To learn more, see the Semantic Versioning 2.0.0 website, or keep reading.

About the Semantic Version Check

When you publish an adapter, the semantic version check completes the following tasks.

Task	More information
Identify changes that break backward compatibility	To identify these changes, the semantic version check compares the previous and current versions of the adapter.
Mandates semantic versioning	The check ensures that yur version number increments appropriately for the type of changes that you've made. For example, if you make a minor release update to version 1.1.1, your next version must be 1.2 or higher.

Task

More information

Identify changes that break backward compatibility

To identify these changes, the semantic version check compares the previous and current versions of the adapter.

Mandates semantic versioning

The check ensures that yur version number increments appropriately for the type of changes that you've made.

For example, if you make a minor release update to version 1.1.1, your next version must be 1.2 or higher.

Types of Updates with Semantic Versioning

Semantic versioning supports the following types of updates.

Type of update	Example	Guidance
Major versions	1.2.3 to 2.0.0	The change breaks backward compatibility or has the potential to break backward compatibility.
Minor versions	1.2.3 to 1.3.0	The change adds new features, such as new functions or parameters, while maintaining backward compatibility.
Patch versions	1.2.3 to 1.2.4	The change improves quality while maintaining backward compatibility.

Changes That Require a Major Version Update

Note:

Currently, the Rapid Adapter Builder doesn't support changes that break the backward compatibility.

The following changes conceptually break the backward compatibility. Whether a change actually breaks backward compatibility for a live integration depends on how integrations use your adapter. For example, if you remove an action from an adapter, you've broken backward compatibility. However, if no integrations are using the action, this change doesn't impact any integrations.

These changes require a major version update.

RuleID	Change
A01	Removing an action or trigger.
A02	Removing the input or output of a trigger or action.
A03	Changing the identifier of an action or trigger.
A04	Removing a property from the input or output schema of a trigger or action. Note: Semantic analysis is not possible when the flow determines the input and output schemas. As a result, when the flow determines the schemas, the change is considered backward compatible.
A05	Adding a required property or changing an existing property to be required for an input schema for a trigger or action.
A06	Changing the data type of an existing field, such as changing from string to number.
A07	Changing a connection property. Updates to some connection properties, including `displayName` and `description`, are not part of this check because these updates do not break backward compatibility.
A08	Changing a security policy.
A09	Changing a security property.

Changes That Require a Minor Version Update

RuleID	Change
B01	Adding an action or trigger
B02	Adding an optional field to the input or output schema of a trigger or action
B03	Changing an existing property from required to optional
B04	Adding or changing enumerated values You can restrict the input values for a property by providing a set of options that the integration developer chooses from. These options are called enumerated values.
B05	Adding a pattern matching regular expression You can use regular expression to specify the allowable pattern and text that an integration developer can enter for a property. If needed, you can add pattern enforcement to a field.
B06	Adding formatting or customizing the user interface appearance of a field You can specify the way that a field is rendered in the user face. For example, when a field has a format of date-time, the user interface displays a date picker.

Changes That Require a Patch Version Update

RuleID	Change
C01	Changing the logic of a flow in a backward-compatible manner without changing the input or output schema, such as an internal change to fix a defect
C02	Changing the properties that define the visual representation of the adapter, including title, description, tags, and icons
C03	Removing an enum from a field, thus allowing the field to accept a wider set of values
C04	Removing a format enforcing regular expression, thus allowing the field to accept a wider set of values
C05	Removing a pattern enforcing regular expression
C06	Changing a test reference when your adapter allows integration developers to test their connections.
C99	Making any other change that is considered backward compatible