Hello there Jorge,

Hope you're doing well.

Basically, when you have a producer and a consumer modules, if you publish a different version of the producer, the consumer will become "outdated".

Behind the scenes, the Platform understands that you have a different version and it is just a way to say that the consumer module was not compiled for the newer producer version and it is running an outdated version.

This happens even if you don't change the signature of an action and it is valid for every new deploy on the producer side. Of course, if you publish the same published version of the producer, it won't have any effect.

However, this applies only for strong dependencies. Are you sure that you don't have a strong dependency between those modules that is causing that behavior?

For weak dependencies it is quite the opposite. Changes in the producer side shouldn't make your consumer to be "outdated" and they should take effect immediately.

Kind regards,

Rui Barradas

Hello Rui,

I have a module only exposing the service with the text "hello"

I only consume that service action, from a 'serviceEu' module

When changing the text to "bye", there is no type of alert in the service studio, since the signature does not change.

But in service center it already appears as 'outdated'.

Kind regards,

Jorge Orellana 

Hi Jorge

Thank you for bringing up this topic, It's interesting.

I thought it's a little weird behavior too. Because this document says service action is loosely coupled elements can be built and published independently 

Kind Regards,

Hi @Jorge Orellana,

I agree it seems a bit confusing for developers, especially for this particular case. However I believe there are still situations where although a consumer may not be impacted directly by the non-breaking changes of a weak reference it is "outdated" in the sense it is not aware of possible changes in the public API - consider for instance the scenario where you add a new optional input parameter, or add an extra output parameter to a Service Action.

All said and done, maybe a better explanation of what outdated means is in order there, but as a workaround "solution" in the meantime, we can teach developers what are non-breaking changes and have them confirm in the consumer if they are actually impacted by them (like @Rui Barradas shows in the SliderValue module's Status)

Cheers!

Hi all

Thank you for your answers.

I understand that somehow the consumer module has to be warned of the change, but it does not seem correct to mark a consumer with non-breaking changes as outdated, since if so, the service center information is not aligned with that of service studio , or maybe it would be good to find another way to warn about this change in the module.

Currently we have a somewhat large factory, with many applications and these types of problems (which are not really problems) take us time with the execution of solutions to try to keep the modules updated before a step between environments.

I already have the necessary information to close the topic, thank you very much.

Kind regards, 

Jorge Orellana