Solved

Named versions seem to move

  • 1 March 2023
  • 5 replies
  • 148 views

Userlevel 4
Badge +5

Since 2023.1 do we have named versions deployed on all environments. But now I am running into the same problem over and over again. The model version from 28-2-2023 15:26:24 was the one that got a name and that name was ‘2023.2.28.2’ now after the deployment we did some more work and today I want to upgrade the test environment from the model version I mentioned first. However for some reason the name (description) with the correct model version ‘2023.2.28.2’ now is assigned to the modelversion of today. So when I select the correct model version the deployment center will nagg about ‘2023.2.28.2’ is not a version you can upgrade from. 

I can ofcourse update the metadata json. Which I currently do. However this should just work. What am I doing wrong? Or to put it better ‘how should I do the deployments?’ I want to use deployment center.

We're not yet using branches.

 

 

icon

Best answer by Mark Jongeling 7 March 2023, 08:58

View original

This topic has been closed for comments

5 replies

Userlevel 4
Badge +5

@Mark Jongeling do you have a clue on this or know anyone who might know the answer?

Userlevel 7
Badge +23

@Mark Jongeling do you have a clue on this or know anyone who might know the answer?

Certainly, I thought one of my other colleagues would reply here actually. 

The moving of named versions happens when a branch with a named version is re-generated (Definition generation). This indicates that the earlier model version is not finalized and this will cause the model version name to be moved to the newly added model version.

When deploying a version to the end product, the model version name should be changed in case you are using numeric names. For development, it is easier to keep the same name as the versioning does not really impact anything.

Only when deploying the version name can help determine the exact moment of deployment. Also the deployment package can only upgrade an end product from a named version to a named version, making named versions required.

So, ensure that the model version name is changed when creating a deployment package and that the source version (the previous model version of the branch) has a name as well.

Hope this helps!

Userlevel 4
Badge +5

Thanks @Mark Jongeling I see, with this in mind I figured that after creating a deployment package we need to clear the field version name when executing the creation. 
 

After this it indeed goes as expected. 

Userlevel 6
Badge +10

@Mark Jongeling We were just playing with this in our SF and noticed that re-using the same ‘Version name’ in the ‘Create deployment package’ task causes the Description in model_vrs to be removed from our latest Production release and added to the last Model version. This does not feel very comfortable to me, I would rather have that Description ‘locked’. Should this behavior not be prevented somehow?

 

Userlevel 7
Badge +23

Hi @Arie V,

The moving of the model version description does indeed happen when the branch uses the same model version description for a previous definition generation.

Model versions cannot share the same description for various reasons. Main reason is making easy to see at what point a certain version was created.

In Model settings, a developer can give the branch a Version name, e.g. 13.1. This name is then used throughout development, and lastly for creating a deployment package. Even if you would generate definitions 10 times, the last created automatically created model version will have this version name. 

After a deployment package is created, the version name should be replaced with a new name. Most often it is an increment, like from 13.1 to 13.2. This is a manual action as the Software Factory cannot determine the created deployment package will be the actual final package of version 13.1. It could be that the created package still contains a problem that has to be resolved. After resolving, a new package can be created with the same name. The model version will be created during that process and be named 13.1.

So yes it is possible for a developer to forget doing this. However, it is possible to edit the model version description in case this occurred. Simply find the model version that was used for deployment and rename it to 13.1. And then also change the Version name of course to 13.2.

It would be an idea to give an indication upon creating a Deployment package that the version name is already present in the Model version table. Feel free to create an Idea for that😄

Hope this sheds light on the topic.