Mark DAPR_GRPC_PORT as deprecated

[erikbosch]

No reason to have both DAPR_GRPC_PORT and VDB_PORT as they fill the same purpose.

Side note: Do we need to discuss how to handle deprecation and backward incompatible changes. Like are we allowed to do backward incompatible changes if next release is a major release? But if so, how do we know if next release on master/main will be a major release?

[lukasmittag]

I agree backwards compatibility is a big issue here. We might even have to talk or tell the Velocitas guys that it is depreceated. I think we should keep it open for now and have at least a little discussion. I think what makes it so difficult is that we have no frequent releases, so people are using our master versions. If we change things it takes immediate effect and they can not use an older version till then. Not only in this case but in other cases I see this problem too. Like the discussion we had in our daily today. @SebastianSchildt @argerus

[erikbosch]

IMHO - we should not have a "special communication channel" to Eclipse Velocitas; my view is that we shall use the same communication channel to "all users". I.e. if we decide to deprecate or remove something and think it needs to be communicated we should use public channels like mailing lists, blogs, or similar.

But we need to discuss how to make decisions. Taking this PR as example there are several decisions:

1. Shall we long-term (some time in the future) remove DAPR_GRPC_PORT?
2. If so, when would it be feasible to remove it?
3. If so, when would it be feasible to mark it as deprecated?

If merging this PR we have implicitly made a decision for number 1 and 3, that we want to remove it long-term and that we can mark something as deprecated at any time. (Giving a new warning could theoretically cause regressions if users use a strict policy where warnings are treated as errors)

[SebastianSchildt]

To 1.) We should get rid of it IMHO. It is not "hurting" much currently, but also not really useful to (I think, I might be wrong) and it always needs to be documented/tested.
I also think, if we agree on that, starting with 3.) is harmless and can be done anytime

We can bring this up in the KUKSA meeting.
wrt to Velocitas at least that is one (the only?) user we know that used DAPR, and this is public. So maybe shout out to @doosuu and maybe @mikehaller
(val-server btw killed DAPR adapter last November, and it hasn't been missed since eclipse/kuksa.val#413)

• How reliant are you on DAPR "functionality"
• How reliant are you on using the DAPR_GRPC_PORT config, now and in the future?