We are moving! We are currently migrating our community to the new Bosch Connected Industry Online Portal. The community will be available latest in the new year again, until then it will be in read-only mode. Click here for more information.
06-19-2023 09:05 AM
Hello,
I have a small feature request for the VersionHistory.xml. It would be nice to have an optional attribute on the ChangeItem node that can mark this change item as incompatible. Then This change item gets a special highlight or small icon or something in the object browser version history and also when reloading STD in OES/CPS.
Reason: I often find myself wondering if I can update to a new incompatible version or if it would be too much of a hassle. So I have to browse the version history, identify which updates were incompatible ones and then scan those updates for the content and try to figure out why this update is supposed to be incompatible, which sometimes isn't easy. A little visual guide would be appreciated.
Any chance this will make it into future updates?
Solved! Go to Solution.
08-28-2023 03:37 PM
As I remember the structure of the version number gives me the information, which is a incompatible and which is an compatible version. If the Major or Minor version number is change, it is an incompatible version.
Versioning Structure of the version number:
Major.Minor.Revision.Build (e.g.: 1.1.4.15)
▪ Change major version number "Major" are large incompatible changes
▪ Change minor version number "Minor" are small incompatible change (renaming of parameters, functions, interfaces, etc.)
▪ Change Revision number "Revision" are compatible changes
▪ Change Build number "Build" are changes for internal tests
I'm right?
08-28-2023 03:51 PM
@PKlein : That's absolutely correct. But I don't think that's what MarvinW meant. Knowing that the new version is incompatible often doesn't help that much if you don't know why it is incompatible. Sometimes, it's just the required tool version being increased that makes the change incompatible. In other cases, the behavior may have changed so that changes in user code are required. At the moment, there is no easy way to find out what the incompatible change actually means for the user.
@MarvinW : Once more a good idea! We will see if this can be improved...
08-29-2023 06:36 AM
With my objects I make in the VersionHistory.xml to the description of the change which is incompatible a *. So you can see which of the changes are incompatible and which were simply implemented.
DE: Bei meinen Objekten mache ich in der VersionHistory.xml an die Beschreibung der Änderung welche inkompatibel ist ein *. So kann man sehen welche der Änderungen inkompatibel sind und welche einfach so mit umgesetz wurden.
08-29-2023 08:28 AM
Yes, and I want something that is a little bit more official than the astersik so everybody knows what it means and it can be supported by the other tools 🙂 It seems nexidator correctly understood my initial requirement.