With the previous version we could set an upgrade script for 1 versions.
Now, when we write a script, and deploy a release, the script is always there. This is not necessary. We can remove it of course, but that is manual labor.
Is this meant to be? Or a minor bug?
Best answer by Mark JongelingView original
I think it did!
@Blommetje, did my reply help out?
I get it, the assignments of Upgrade control procedures 😄
You can assign these Control procedures in two ways:
The program object looks like one of the following:
(XXXX = model version name)
This does require the model version to Use upgrade logic. This can be enabled for any created model versions with the prerequisite that the model version has a name (model version description).
Hope this helps!
Reading my question back I see it’s unclear. Yes, the upgrade is not a problem.
What I mean is, the Functionalities with an UPGRADE code group.
This code is also executed every time we create a deployment package. And usually we only use this for removing values when changes Elements, for example. So, we do this once. and everything is ok.
No need to do this everytime.
Hopefully this explains it a bit better.
The upgrade script is indeed pretty much always active as when you upgrade your end product, the source model version is updated to be equal to the model version that has been rolled out on the database. Even without any changes, the upgrade script is active as the source model version equals the one on the end product.
There should not be any harm in upgrading your end product every time. We also automatically upgrade our end product Software Factory every night due to this.
Feel free to create an Idea to expand the Upgrade script checks in a way that it only gets active when it's really needed 😄