Component versioning involves keeping track of the current state of an object or group of objects in the database, so that consumers know how to talk to the current state.

This approach involves updating consumers in advance of database changes, allowing these database changes to be performed in a simpler manner without the need for backwards compatibility logic.

Application developers can instead write this logic in their native language. 

Using a dedicated table and static data

Component versioning consists of creating a table dedicated to holding the versions of different components within the system, where a component could be an individual object, a group of objects (for example, all the objects in a schema), or the whole database.

The data is stored statically so it can be controlled as a schema change.

Whenever a release is needed, versions can be updated in the same transaction as the accompanying object changes they represent. 

Known issues

Programmable objects do not work well with component versioning and should be avoided. 

• If any custom transaction handling is needed, it is near impossible to group programmable object changes into the same transaction as changes in migration scripts.
  They will by default run in the same transaction as the last migration, but where transaction customization is needed in the migration scripts this can’t be guaranteed to be correct. 

• You cannot deploy iteratively (that is there can be no intermediate steps during deployment, as we always just delete the object and replace it with the latest version after all the migrations have run). This can be needed to ensure backward compatibility. 

• Combining the programmable objects feature and component versioning magnifies the dependency ordering issue between programmable and non-programmable objects.