Mambu Release Flow
  • 12 Oct 2020
  • 6 Minutes To Read
  • Print
  • Share
  • Dark

Mambu Release Flow

  • Print
  • Share
  • Dark

Release Types

For product update, we aim to use the continuous delivery model, which allows us to seamlessly provide updates to our product and react faster if an issue should occur.

For added clarity, we divide our releases into three types based on its content and the impact it has on your operations, allowing you to know if you need to take any action when a new release is performed.

Identifying the release type

The release type is specified in our release notes. We also follow the principle of semantic versioning for our releases, allowing you to easily identify the release type based on the version change.

Semantic versioning

Semantic versioning is a 3-component number in the format of X.Y.Z. Depending on the release type, we will increment the corresponding component number, as described below.


  • Increasing the value of X indicates a Breaking Change release.
  • Increasing the value of Y indicates a Feature release.
  • Increasing the value of Z indicates a Patch release.

Patch releases

The Patch release is a type that requires no action on your side, as it brings along only bug fixes and improvements that do not change the way Mambu features behave.

Patch releases will be rolled out to Sandbox environments as soon as available and on Production Environment shortly afterwards (it can even be on the same day).

Frequency: Very often ( > 1 per week)
Action required: None
Email notification: No

Please be Aware
Mambu will not give notice for Patch releases, as these will have an increased frequency and no impact on your operations; the corresponding release notes will be created and available on our community page.

Feature releases

The Feature release is a type that requires action on your side only if you plan to use the new features that are brought along with it. It has no impact on how existing Mambu features behave.

Feature releases will be rolled out to Sandbox environments as soon as available and on Production Environment shortly afterwards (it can be on the same day).

Frequency: Often (± 1 per week)
Action required: Optional
Email notification: Yes

Breaking Change releases

The Breaking Change release is a type that requires action from your side as to ensure that you are able to use the feature in its new form. By new form we refer to changes in the API contracts (i.e. definition of the API inputs and outputs and API specifications) or in the behaviour of existing functionality.

Frequency: Rare (on a need-basis)
Action required: Mandatory
Email notification: Yes

When planning for a breaking change, we will evaluate if we can keep backwards compatibility as to allow two behaviours of the feature in parallel. As there may be cases where this is not possible, we will approach things differently, as follows:

Scenario 1 - Backwards compatibility maintained

In this scenario, we will release a breaking change and will ensure that we will keep both the new and old behaviour running in parallel for a period of three months (or more, depending on the case). This will give you time to adapt your workflows/integration as to work with the new behaviour.

When the backwards compatibility period ends, the old behaviour will be removed.

Scenario 2 - No backwards compatibility

When backwards compatibility cannot be maintained due to technical constrains, we will send out an announcement three months ahead (or more, depending on the case), informing on what is going to be changed and an estimated date on when it will be released.

When the release will be done, the old behaviour will be replaced by the new one, and, as such, you should update your workflows/integration beforehand.

Please Note
It may be the case that you are not using the updated feature or API contract, and in this case, you won't have to perform any action in preparing for the release.

Release types inclusion policy

Betwen the release types there is an inclusion policy. A Feature release can include content from the Patch release (bug fixes and improvement), whilst a Breaking Change release may include the content from both Feature and Patch releases.

Release Inclusion

Database Changes

It may be that from time to time Mambu will update the database structure, as to accomodate new use cases or maintenance (e.g. updating to a newer version of the database engine).

Where are the changes published?

If updates are performed to the database data structure, we will publish these alongside the release notes, with a dedicated section labeled "Database Changes".

What impact would these changes have?

If the database structure would be changed, then this could impact the following areas:

  • Data Import
  • Jasper Reports

Rest assured, if we are to perform a change in the data structure, this would be promoted via a Breaking Change release.

Audit Trail UI Contract Changes

The UI actions that are registered in Audit Trail may change over the course of time as a side effect of adding, removing or changing existing Mambu UI functionalities. These changes will be published before the Sandbox release so that you have time to make any alterations on your side if needed.

Where are these changes published?

Similar to “Database Changes”, the Audit Trail actions changes are published alongisde the release notes, in their own section titled “Audit Trail UI Contract”.

How are these changes published?

For every change in the actions registered in Audit Trail, we will present the changes in the release notes, in JSON format.

The “Audit Trail UI Contract” is split in two parts:

  • Added actions sub-section. Here you will find all the new actions that will be registered in Audit Trail.
  • Removed actions sub-section. Here you will find all the actions that will no longer register in Audit Trail. Actions might appear in this section due to action name changes (or resource/method).

Note: Modified actions will appear as removed and added. This means that the old name of the action will appear in the “Removed actions” sub-section, and the new action with the new name will appear in the “Added actions” sub-section.

What impact would these changes have?

The impact will be visible when retrieving the events registered in Audit Trail. These changes do not impact events that were previously registered in Audit Trail.

Mambu Release/Incident Notifications

Mambu notifies customers on upcoming releases or possible incidents via StatusPage.

In order to make sure that you are always up to date with our releases and possible incidents, please ensure that at least one key person from your organisation is subscribed to our notifications, by following the steps below.

1. Go to if your organisation is on a Shared Environment (for private environments, see note at the end)

2. Hit Subscribe to Updates


3. Choose how you wish to be notified (email, SMS, etc.)


4. After subscribing, you will receive an email confirmation. You can follow the link in that email for Managing Subscriptions in order to subscribe for the region (component) you need, otherwise you will be notified for all regions.


For Private Environments, please reach out to our support team, they will gladly provide you with the link to your dedicated Status Page, in order to receive notifications for your environment. The above link is only for shared environments.

Once your details have been submitted, you will be notified automatically on release dates and time. Anyone in your organisation will be available to subscribe to this page.

Please be Aware
For releases of type "Patch", we will operate under the "silent release" process, meaning we won't send out notifications when performing releases.
Was This Article Helpful?