Hi Alex,

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 

Hi Mark, 

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. 

Alex 

Hi Alex, 

I get it, the assignments of Upgrade control procedures 

You can assign these Control procedures in two ways:

• Always, meaning every Upgrade you do the control procedure template code will be weaved into the Upgrade code file
• From a specific model version, meaning when the source version of the branch is set to this model version, the control procedure template code will be weaved into the Upgrade code file (2023.1) - (2022.2 and before = from project version to project version)
  The program object looks like one of the following:
  • ug_before_upgrade_from_XXXX
  • ug_during_upgrade_from_XXXX
  • ug_after_upgrade_from_XXXX

(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!

Hi @Blommetje, did my reply help out?

I think it did! 

Thanks!