Enhanced Versioning for Components, Integrations, and Instances

Versioning has been improved for components, integrations, and instances to give you more fine-grained control over exactly what code is deployed to customers.

Components are now assigned an integer version that increments each time the component is published. If a custom component is at "version 3" and you publish a new component definition, that new definition gets "version 4". This allows you to update or extend components without unintentionally impacting existing integrations that use them, ensuring your integrations remain stable. Integration builders can then update the component versions used in their integrations, or roll back to a previous versions when desired, and will be notified when newer versions of components are available.

Read more about Versioning of Components and Choosing Components Versions in Integrations.

Integration versioning has been improved, giving you more control over what versions of integrations you deploy to customers. When you publish new changes to an integration, similar to components, your integration is assigned a new version number. Then, when you deploy an instance to a customer, you can choose which version of the integration to use. That means you can have some customers on version 1, and others on version 2 as needed, giving you control over which customers have what, and allowing you to test a new integration version with a small subset of your customer base before deploying it broadly.

Rolling back an instance deployment is a breeze - if you deploy a new version of an integration to a customer and something seems off, you can easily roll back your instance to a known working version of the integration with a couple of clicks.

As always, updating customers' instances can be scripted, so you don't need to manually deploy a new version of an integration to each customer.

Read more about Publishing an Integration.