Often, I see that versioning is an overlooked aspect of integration lifecycle management. In this post we will look at a simple, but critical aspect of OCI Integration – Versioning. It’s important to understand your versioning controls and the impacts that they can have on your integration solutions. This post is relevant for both Oracle Integration Cloud gen2 and the more recently released OCI Integration 3 where both support semantic versioning.

---

What is Semantic Versioning?

Semantic versioning is a widely used method of version control. Having a universal method of identifying and versioning components within software development is the most straightforward way of tracking what is going on with the software you have/are developing. This method – Semantic Versioning – is composed in the form of Major.Minor.Patch. Where each are represented as follows:

Version Type	Version Position	Version Description	When to Increment
Major	The leftmost number	When you increase a major version, you increase it by 1, but you reset the minor and the patch numbers to 0. For example, if the current version is 4.3.7 then your next Major version is 5.0.0	Typically used to represent lack of backwards compatibility
Minor	The middle number	When you increase a minor version, you increase it by 1, but you reset the patch number to 0. For example, if the current version is 4.3.7 then the next minor version is 4.4.0	Typically used to represent new functionality
Patch	The rightmost number	When you increase a patch version, you increase it by 1 without resetting any other numbers. For example. If the current version is 4.3.7 then the next patch version is 4.3.8	Typically used to represent a bug fix

There is a common misconception that when you get to x.x.9, the next increment should increment the minor version rather than the patch version. This is not true and breaks the semantic versioning model. The next version after x.x.9 is indeed x.x.10. There isn’t a limit to these numbers, you could have 10.104.8920 for example.

Note the following key points:

• The first version number of the semantic versioning model, as mentioned above, is 0.1.0 not 0.0.1 as we start with building features, not fixing bugs!
• Versions that precede v1.0.0 are reserved for development phases only

Why Does This Matter?

During activation of an OCI Integration Instance, the version number matters. If integration ABC/01.00.0000 is activated and you go ahead with activating ABC/01.00.0001, then ABC/01.00.0000 integration would be automatically deactivated before ABC/01.00.0001 is activated based on your request. There would only be one activated integration in this case (it would be the latest version)…. HOWEVER, if ABC/01.00.0000 is currently activated and you request to activate ABC/02.00.0000, both integrations will be active at the same time – same goes for deactivating.

Show Me!

Here we have an integration named “ASG_SEMVER_DEMO”, the version number is 00.01.0000 (or 0.1.0). The status of the integration is currently “Configured” (aka, the integration has not been activated):

Here, I have selected to “create a new version” of the ASG_SEMVER_DEMO integration. You will notice that OCI Integration automatically populates the version number as 00.01.0001 (or 0.1.1), but you can change this if you wish. Again, the status of the integration is currently “configured” (aka, the integration has not been activated):

Now, what happens if I activate those integrations? Remember, I currently have 2 versions of the same integration. The first is my first development version of the integration (0.1.0) and my second is a bug fix (0.1.1). Firstly, I will activate v0.1.0:

Next, I will try to activate v0.1.1:

Notice how I receive a warning that reads “Activating integration ASG_SEMVER_DEMO (0.1.1) requires deactivating integration ASG_SEMVER_DEMO (0.1). Are you sure you want to deactivate integration ASG_SEMVER_DEMO (0.1)?”. When I click to activate, you will see that the status of v0.1.1 becomes “Active” and the status of v0.1.0 changes back to “Configured”.

It is not possible to have a patched version active which contains the same minor version number.

Now, what happens if we create another new version, but this time we add a new feature to make a v0.2.0 (note, I have reset the statuses to “Configured”):

Now, what happens if I activate those integrations? Remember, I currently have 3 versions of the same integration. The first is my first development version of the integration (0.1.0), my second is a bug fix (0.1.1) and lastly, is a new feature (v0.2.0). I will first activate v0.1.1 (my most recent version before I created a new feature):

Now, Let me try and activate v0.2.0:

Notice – again – how I receive a warning that reads “Activating integration ASG_SEMVER_DEMO (0.2) requires deactivating integration ASG_SEMVER_DEMO (0.1.1). Are you sure you want to deactivate integration ASG_SEMVER_DEMO (0.1.1)?”. When I click to activate, you will see that the status of v0.2.0 becomes “Active” and the status of v0.1.1 changes back to “Configured”.

What will happen if I try to activate, my original feature version (v0.1.0)?:

You guessed it! I receive a warning that reads “Activating integration ASG_SEMVER_DEMO (0.1) requires deactivating integration ASG_SEMVER_DEMO (0.2). Are you sure you want to deactivate integration ASG_SEMVER_DEMO (0.2)?”. When I click to activate, you will see that the status of v0.1.0 becomes “Active” again and the status of v0.2.0 changes back to “Configured”.

Now, I will create a version 1.0.0 of this integration.

I will activate it:

I will create another feature version (v1.1.0:

Look what happens when I try to activate the new feature:

And for completeness, I will create a patch version of this too:

Again, look what happens if I try to activate it:

So, the only thing left to try is another major version. Here I create a v2.0.0:

And try to activate it:

A-HA!!! Success. Both v1.0.0 and v2.0.0 can be activated at the same time. Now I can run 2 versions in parallel for service consumers.

Summary

Major: If there is change in the Major version then more than one integration can be activated at a time. For example: Both the integration with versions 01.00.0000 & 02.00.0000 can be activated a same time.

Minor/Patch: If there is change in the Minor or patch version then only one integration can be activated at a time. For example: Only one integration with the versions 01.00.0000 & 01.01.0000 can be activated at a time.