Several Object Browser issues

[MarvinW]

Hello,

I have some feedback for the Object Browser.

The first is about version management. When we are preparing a new object version, we use the last digit for test releases. I think this is also how BCI is doing this, although it has been many years since I had such a BCI object in my hands. Anyway, my problem is that the test versions are thus ranked as newer than the final release version, which uses 0 for the last digit.

For example, I am upgrading an object from 1.0.0.0 to 1.0.1.0. But before I can release the new version, I give an object version 1.0.1.1 to my colleagues in the field for testing. Then after I confirm everything is fine and maybe fix some bugs they found, I will finally release 1.0.1.0 on our release repository. But the colleagues who have 1.0.1.1 in their STD will not be displayed the release version when they are looking for compatible updates, because the last number 0 is lower than their test release number. And when they select it manually, it is also labeled as "compatible downgrade" in the download dialog. My suggestion is to treat the last digit special, where 0 is the newest version and any other number is using normal sorting. Maybe this could be enabled or disabled with a setting of the Object Browser.

My second point is a question. After updating my STD I found that the Object Browser downloaded all 3 available versions of the Mode Handler Template when I updated some other objects. It was not even selected though for download. I think this is because I have no version of this object in my STD at all, but I downloaded another object that has hierarchyNodeType="ModeHandler". But I don't know if this is the cause or not. Anyway, I wish the object browser would not download any unwanted objects that I did not select and that are not a dependency of any object in my STD.

The third one is a feature request. I would like to be able to automatically download all objects (and peripherals) based on an ObjectVersions.xml file that OES generates in the Engineering folder. Or alternatively it could be from an Object Usage file (because that is created from the ObjectVersions anyway, correct?). The point is to reduce the size of our base station backups. With this feature, the person who creates a new STD for a project can get the base station project (only the Stat folder) and then use the object browser to download the STD conveniently and then update the objects that are in use. As a bonus, I would like to be able to select more than one station folder (ObjectVersions.xml file) for this purpose.

[Thorsten_Brach]

Hello Marvin,

1st point :  I would suggest to change you version-jump process :

if you have a V1.0.0.0 and you are developping a new version, jump to V1.0.0.1 ... V1.0.0.XXX until your developing is done.
Then you can release the new version as V1.0.1.0 - so your customer can always update from an older version to a newer version...

2nd point : must be answered by an object browser expert - I use the object browser only rarely...

3rd: point: as far as I know, this feature has been implemented in the meantime - I had also wished for it several times 😉

[MarvinW]

About point 1: The way you propose for updating versions is not a reasonable solution in my opinion, because it masks the type of update you are doing: compatible or incompatible. What's next is that it is impossible to distinguish which target version a test version is supposed to become. For example, 1.0.0.1 could become 1.0.1.0, 1.1.0.0 or 2.0.0.0. Or even 1.0.2.0, if the developer skipped a number for some reason. So if I see an STD with the test version 1.0.0.1, I cannot tell which version I am *supposed* to update to. Well I guess I could simply strive to update to the latest that is available. But overall this process is not good enough in my eyes. I like my initial proposal more 😛

About point 3: There is a function that allows you to create an STD from an existing STD through the project creation wizard. That is somewhat similar to what I want to do, but not quite the same, because it requires that you already have an STD with the correct files somewhere. Although, if that is using only the .ood files then maybe that would be good enough for my use-case. If anybody knows of a way to do it purely from the Station folder though, that would be great 🙂

[nexidator]

About piont 1: I understand your suggestion and it might have been a good idea to start like this 9 years ago, although I am not even sure about this. I think it is still easier to understand that higher version numbers are higher... 😉

But I definitely don't think it is a good idea to change the behavior now. It's not only the object browser but also Control plus Studio that is affected by such a definition. And as object definitions are often usable by many OES/CpStudio versions it is impossible to get a consistent behavior in all tools if we change this definition.

So, the way Thorsten suggested is the right direction. About incompatible versions: Yes, the test version needs to show the incompatibility as well. For instance, when you are planning to move from 1.2.3.0 to 1.3.x you should start the test versions at 1.3.0.1. This means that the first release will be 1.3.1.0. That way, 1.3.0.0 will never exist, but I don't see a technical problem with that.

[SteffenR-]

1) Like the previous responses told already: never decrease a version number, only increase. Decreasing only makes chaos in the applications 😀
Nobody cares if the version numbers in the version history have some gaps.

2) Remove this checkbox to not update the dependencies. Maybe this helps. To update existing/running machines, this checkbox must always be removed to have full control over the update process. Unfortunately the checkbox setting is not saved.

3) Create your Std with ObjectVersions.xml:
Select import, then chose an ObjectVersions.xml file: