Currently, we are using IBM API Connect as our API management solution. It works by grouping APIs (OpenAPI yaml files) in a product (A yaml file) and each file has its own version. An example would be product_1.0.0.yaml having a reference (relative path) for the files api-1_1.0.0.yaml and api-2_1.0.0.yaml respectively.

The APIs versions change according to Major.Minor.Patch and their products change accordingly. We have different environments such as DEV, SIT, UAT, & Production.

Now each BR reflects to changing the APIs and/or products versions (file names too) on DEV environment. For example 3 BRs reflects to three version changes (api-1.1.0.0 -> api-1.1.1.0 -> api-1.2.0.0 -> api-1.2.1.0).

The problem is that sometimes we have BRs with different priorities (Sometimes these priorities are not evaluated during development), so some BRs are required to be deployed to production before others (Other BRs could be delayed because of issues, approval, ..etc.). But as we can see if we choose the BR that reflects to V2.1.0 this means that we also include the changes happened in V1.1.0 & 2.0.0 which could be not backward compatible (such as V2.0.0). So what should I do If I just want to get only the changes made for the BR (excluding changes in 1.1.0 and 2.0.0 especially if they are not backward compatible)? Also, we need to be able to roll back to specific version with all dependencies (Products and their APIs).

My current approach was to represent versions by git tags and for deploying specific BRs, I include other changes if they are backward compatible (Represented by the X.Minor.Patch part of the versioning) and in case they’re not (Represented by Major.X.X) then I cherry-pick/rebase the changes I want but the issue is by doing so I am creating a new version that is totally different from DEV environment.

I do not even know if Git should handle such case!