Hello Magnus,

While the OptionalConfigs input parameter is not mandatory, I understand that being a block input parameter it will cause all modules that reference it to be marked as "Potential Incompatible Consumer", because the element signature has changed and blocks generate strong dependencies. 

Refreshing/Republishing the affected modules, in this case, will solve the situation, as there is no need to actually change your code unless you want to use the new feature. Most likely the functionality is the same (don't quote me on this, please).

If the old functionality is fine, you can ignore it for the time being, as the published versions of the consumers will continue to use the old version of the block (due to the strong dependency). 

But I understand that this may lead to the environment to look "broken/outdated". 

I don't think creating a new block is the solution though. While right now, republishing the modules fix any issue, a new block would require the original one to be marked as deprecated and eventually would require some manual intervention in order to replace all the old blocks with the new ones. 

This is done mostly when there is a complete rewrite of the underlying code and connection to other features.

Usually, whenever there is a new version of OutSystems UI (and other libraries), it's a good practice to check what are the changes and the breaking changes, so you can decide if it is something you can do now, or if it will cause an undesired impact and you chose to postpone the update until you can perform any fixes that may be required.

Well, that's my view on the topic. 

Cheers!

I agree with @Eduardo Jauch that this (a new optional input) is not a reason for a new version.  

But there is something funny going on in the platform with this type of change.  Other changes, like an input becoming mandatory, or an element being deleted, are flagged by a warning when opening a module or when trying to publish, with a 'missing or incompatible dependency' popup, with the options to manage dependencies or to cancel.  And in the dependencies manager, the module is yellow, indicating something needs attention.  In case of choosing cancel when publishing, it goes right ahead and publishes with success.

This change (a new non mandatory input on a block) does not cause the warning popup, and the module is not yellow in the dependency manager, so all looks cool and postponable, but then you get a compiler error when trying to publish.  And to make things even more confusing, if you try to publish from service center, the compiler error doesn't happen.

The platform somehow is not consistent in how it deals with this type of change, in my book a platform bug.

A completely different remark : I would advocate to actively process new versions of a producer as a task to be executed, tested and deployed forward, not as something that will get picked up as and when a consumer happens to get worked on.  Even when there are only implementation changes, it deserves some TLC and regression testing.

A trick to avoid having to open each consumer and refresh dependencies manually, is to publish all consumers from the producer page in Service Center.  This will BOTH refresh the dependencies and republish.  It does take a while, so I would plan for something like OutSystems UI during unbusy time.  This will tell you exactly what consumers can just refresh and go, and which consumers need attention. 

You'll have to start it again after fixing all the consumers that need it, to actually make it go through with deploying everything. For example, the consumer that could be refreshed did get a new version, but is not published yet.

Dorine

Hi Magnus.

That new option is mandatory or not?

Best regards

Pedro Jesus

Hello 👋🏼

The change was indeed unclear on the release, and that is already fixed as a change.
Other than that, this is a new non-mandatory property that will add improvements in terms of accessibility in a way that is less disruptive, so the customer can opt in on making the component more accessible. Accessibility and security are two non-negotiable topics when we get any findings, and because of that, we always avoid breaking changes, and this is indeed not a breaking change (no runtime impact), but the way the O11 platform makes it sometimes in a blurry space and for that (like in any other consumer or even technology), an upgrade plan should be in place at least for minor and major.

Best Regards,
GM