Skip to main content
Solved

Named versions seem to move

Kasper Reijnders
Forum|alt.badge.img+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.

 

 

Best answer by Mark Jongeling

Kasper Reijnders wrote:

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

View original
Did this topic help you find an answer to your question?
This topic has been closed for comments

5 replies

Kasper Reijnders
Forum|alt.badge.img+5

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

Marius Korff
1 person likes this
  • Marius Korff
    Marius Korff
Mark Jongeling
Administrator
Forum|alt.badge.img+23
  • Mark Jongeling
  • Administrator
  • 3940 replies
  • Answer
  • March 7, 2023
Kasper Reijnders wrote:

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

"Wake me up before you low-code"
Kasper Reijnders
Forum|alt.badge.img+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. 

Mark Jongeling
Marius Korff
2 people like this
  • Mark Jongeling
    Mark Jongeling
  • Marius Korff
    Marius Korff
Arie V
Community Manager
Forum|alt.badge.img+12
  • Arie V
  • Community Manager
  • 992 replies
  • April 21, 2023

@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?

 

E
Kasper Reijnders
2 people like this
  • E
    Erwin Ekkel
  • Kasper Reijnders
    Kasper Reijnders
Mark Jongeling
Administrator
Forum|alt.badge.img+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.

 

"Wake me up before you low-code"
Terms & ConditionsCookie settings

Cookie policy

We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

 
Cookie settings