---
title: "Data Vault Releases"
canonical: "https://docs.vaultspeed.com/space/VPD/3011641397/Data%20Vault%20Releases"
format: markdown
---
VaultSpeed works for your data vault with releases, the same way it does for sources.
When you click on the name of a data vault in the 'data vaults' screen, you will automatically go to the **Releases** screen. Here you can add a new release by using the '**+ Release**' button.
You will have to give the release a name, a number, and a comment. Then you can select for each source related to the same project in which this data vault is built which source release should be used.
### Selecting Source Releases
When creating a Data Vault Release, you have flexibility in choosing which Source Release to use for each source in your project:
> ℹ️ Only locked source releases are available for selection
> ℹ️ Make sure to add a check to any new sources you need, as by default the new release only uses the sources previously used.
> ⚠️ Special characters are not supported in the Release Comments!
Once your release is created, it is available in the **Releases list** with all the releases for this data vault. The sources option on the action menu shows all the source releases used to create a certain data vault release.
At the end of the line of your release overview, the lock icon shows whether this release is locked or not. You can edit your data vault release if the lock icon is open.
## Locking a Data Vault Release
Once you have gone through all the configurations of your data vault release, you need to lock it (see [https://vaultspeed.atlassian.net/wiki/spaces/VPD/pages/3040477208](https://vaultspeed.atlassian.net/wiki/spaces/VPD/pages/3040477208)). A locked release is indicated with the closed lock symbol.
### Warning When Using Historical Source Releases
If you lock a Data Vault Release that is based on a Source Release that is **not the latest Release** (i.e., an older, historical source release), VaultSpeed will display a warning message to inform you about the parameter behavior:
> ❌ **Warning Message:**
> ❌
> ❌ *"You are creating a Data Vault Release on an older Source Release, which means that the Current Parameter settings for the Source are used for this Older Source Release"*
**What does this mean?**
When you create a Data Vault Release based on a historical Source Release, the Data Vault will be generated using:
- **The model** (tables, columns, constraints) from the historical Source Release
- **The parameter values** that are currently configured in the Source (not the parameter values from when the historical release was created)
This behavior is important to understand because any changes made to source parameters after the historical release was created will be applied when generating the Data Vault, even though you're using an older source model.
## Setting a production date
After locking your data vault release, you will notice that your release still has a status of 'prototype', indicated by the prototype slider.
A data vault release in type 'prototype' means that all changes that you made in this release, compared to the previous 'production' release will be taken over to your data vault modelling. Eg: All new objects will be added to the model, all renames or other changes to new objects will be taken into account in this release.
Once you have deployed your data vault release to your environment and you are fully happy with how it looks like and works, you should also upgrade that release in VaultSpeed to a 'production' release. This means that you will lock all objects and attributes in place for this release, and they can never be edited anymore afterward. You can only add new objects or add attributes to already existing objects from that point on.
To set a release as a production release, the Production Date field should be filled in. To do so, click on the 'Upgrade' button and set a production date.
> ⚠️ Objects (and attributes) in a Data Vault Release with a Production Date cannot be deleted. Setting the Production Date will also Lock the Schema, Object, and Attribute Name Parameters since these should not be changed after Deploying a Data Vault to prevent Problems.
## Removing a production date
To remove a production date, click on the downgrade button, which appears after a release has gotten a production date.
You will get a message explaining to be very cautious about removing a production date. You have to confirm that you have read the message and enable a checkbox before you can click the confirmation button.
> ⚠️ CAUTION : Don't remove the Production date for a release in VaultSpeed that is deployed to your running Production System.
Removing the production date **should only be used** for VaultSpeed releases that are **NOT in Production**.
The first and most frequently encountered case is using it during the prototyping period of your project. Setting and removing all the production dates at that period allows you to play around, understand the VaultSpeed application, create the proper naming conventions for the Schema, Objects, and Attribute Name Parameters, and test the results of Full and Delta Generation.
A second case could be that you accidentally put a production date for a release that will not go into Production.
Let's look at the 2 cases and which steps to take to ensure you have the right outcome after removing the production date.
### Case 1: Removing all the production dates
Let's take the hypothetical case that you are in your first pilot project and already have one production release and that you want your HUB prefixes to be changed from HUB_ to H_ and Satellite prefixes from SAT_ to S_.
You do not want to lose all the changes you made during the different releases.
#### T1
At T1, you have your empty VaultSpeed repository
#### T2
At T2, you **added** several objects to your model and created Release 2, including the object: **SRC1.Table2**. This source object will, on your data vault, result in the objects **Hub_table2** and **Sat_table2**.
#### T3
At T3, you **removed** the object **SRC1.Table2** from the model and created Release 3.
Because you have set a **Production Date** for **Release 2**, a **Delta Generation** will be executed when generating Release 3 from the database.
The result **will be that after the Delta Generation, the tables Hub_table2 and Sat_table2 will still exist because of the audit requirements of the Data Vault 2.0 standard.**
#### T4
At T4, you notice that your naming convention of the Hubs and Satellites is wrong, and you want to change them.
The only way to **change the Naming Conventions** for **Objects** is by deleting **ALL the Production Dates** in VaultSpeed.
In our example case, we must remove the **Production Date** for **Release 2.**
However, removing the Production Date of Release 2 will render Release 3 unusable because it holds only the changes done in Release 3.
It means we **must create a new release, Release 4,** that will take on the scope from T1 (the empty repository without any objects defined) to T4, meaning all the changes made until Release 3.
There is no Production Release anymore, and a **Full Generation will need to be executed.**
No Delta rules will be applied as it is a Full Generation, resulting in you **not** having **Hub_Table2 and Sat_Table2** in release 4.
As you are still in prototype mode, you can drop and recreate all structures using the Full Generation and do the initial and subsequent incremental loads when new data arrives.
However, if you are **not in prototype mode**, you can imagine that you will **lose data** when recreating the structures and reloading. More specifically, **any history** that is not available anymore in your source systems can be lost, as well as the **content of** **Hub_Table2 and Sat_Table2.**
### Case 2: Removing an accidentally added Production Date
Let's take the hypothetical case that you have set a Production Date, and developers moved on to the next release with new features. However, the Business Users needed the new features sooner and wanted to go into production with the next release.
In this case, you want to be able to remove the production date.
#### T3
Let's assume you are at T3 and you executed the following steps:
- A *Delta generation* for *Release 2***,** and you deployed it to your "Dev Testing" system.
- Setting a *Production Date* for *Release 2*.
- A *Delta generation* between *Release 2 and Release 3*, and you deployed it to your "Dev Testing" system.
#### T4
At T4, The business decides not to go into Production with Release 2 but with the scope of Release 3.
In our example case, the **Production Date** for **Release 2 will be removed** as this release will not go into production**.**
However, removing the Production Date of Release 2 will render Release 3 unusable because it holds only the changes done in Release 3.
We **must create a new release, Release 4,** that will take on the scope from T1 to T4, meaning all the changes made until Release 3.
> ℹ️ ### General Rules for Removing a Production Date
> ℹ️
> ℹ️ - Do **NOT delete a Production Date** when that release is running in Production.
> ℹ️ - **Always create a new release** when a Production Date is removed from a Data Vault Release, and there is a Locked Data Vault release after the Data Vault Release with the removed Production Date.
## Creating subsequent releases
When creating new data vault releases, you can select the previous release as the basis for the new one.
> ⚠️ **Important:** You can select any previous data vault release as the basis for your new release. By default, the most recent release is preselected.
## How to Reverse Your Data Vault Release and Linked Sources to the Original Source Versions
When reversing a Data Vault release, VaultSpeed will automatically select the latest locked release of each source.
> ℹ️ **Important Note:** In most cases, this automatic selection won't cause issues. However, if you encounter any warnings or errors, it is crucial to manually revert the Source Version Releases to the versions associated with the old Data Vault Release.
To do this, follow these steps:
## Steps to Reliably Reverse Your Data Vault Release
1. Navigate to the Data Vault Release you want to revert to.
Make screenshots or take note of all the Source Version releases associated with the old Data Vault Release.
2. **Create the New Data Vault Release:**
This screen allows you to input the release name and number, and to specify the previous release as the basis for the new release.
- Create the new Data Vault release using the exact source versions you documented in the previous step.
- Begin by providing a new release name and number.
- In the "**Based on previous release**" section, select the previous Data Vault release that matches the one you want to revert to.