Impact of protocol version changes

Below, you can find an overview of all changes to a protocol that can cause impact when updating from a previous version. Some of the changes can be implemented using workarounds where the impact can actually be avoided.

For more information on protocol version numbering, see Protocol version semantics.

Important

When an impacting change is implemented, a range change is required.

Protocol version requests

A protocol version request needs to be made as soon as a change in a protocol will cause impact and no workaround can be implemented.

As a Skyline developer, to create such a request, go to the Protocol Version Request page on Teams.

A team of System Developers is responsible for following up on these requests and guiding the developer to make the correct decision and assess if the impacting change can be implemented or if a workaround is possible.

Depending on whether the request is valid or not, the request will either be approved or rejected.

It is important to assess if a major change will be needed as soon as possible to avoid any delays that could impact the delivery of a task.

Impacting changes

There are many protocol changes that can cause impact.

Causing impact means that if you have an existing element using a previous version of this protocol, you cannot upgrade to the new version because something in your system will (or might) break depending on what specific features of the protocol or DataMiner are being used.

The impacted changes listed here are grouped based on the change that is implemented.

Protocol changes

• Change DCF
• Change Unicode
• Change connection(s)
• Change layout
• Change exported protocol name (DVE)
• Change page name
• Change minimum required DataMiner version
• Change protocol name
• Change InterApp range

Parameter changes

• Change parameter description
• Change parameter ID
• Change parameter discreet and/or exception
• Change parameter Interprete
• Change parameter range
• Change matrix parameter size
• Change alarm monitoring and/or trending
• Remove parameter

Table parameter changes

• Change primary Key
• Change display key
• Replace displayColumn by naming
• Change to partial table
• Change logger table
• Change column order
• Change displayed column order

Improving context awareness procedure

A procedure has been introduced to improve context awareness and to allow certain major changes to improve the overall quality of protocols even though they could cause impact.

Context awareness

Any user familiar with a product should easily find all necessary information when using DataMiner protocols. This means that DataMiner protocols should not only perform great, but should also look the part and be straightforward to use.

Especially for new developments, the focus should be on getting them spot on from the start, especially since any changes that might be needed in the future could cause impact for existing users.

However, this should not stop you from improving existing protocols.

Major changes

In the past, as many major changes as possible were blocked by providing workarounds or convincing the users to not make certain changes to avoid impact. While this worked, this meant new users might not get a perfect product. To improve the quality of DataMiner protocols, a different approach is therefore needed.

Procedure

Whenever you receive feedback from a user that some improvements (changing parameter descriptions, change layout, etc.) could be done in a protocol, a major change can be requested to allow these changes.

As a Skyline developer, you should create such requests on the Protocol Version Request page on Teams (similar to any other protocol version request), but no specific task is needed (unless you already have a task in your project).

The Protocol Version Request team will evaluate the requested changes and, when the request is valid, they will create a task in the SLC-SE-Internal Protocol Reviews project.

Note

The Protocol Version Request team is in charge of creating these tasks, and no tasks should be created in this project without the team knowing about it.

Tasks

Whenever you are working on a task for a protocol, please keep an eye on this project and see if no other improvements could be taken along.

No additional version request is needed anymore as these changes were already approved.

This is also a call to all Product Owners to keep an eye on this project and try to get these tasks picked up whenever changes are done in the protocols of which they are the owner.