Closed erikbosch closed 11 months ago
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:
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)
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 https://github.com/eclipse/kuksa.val/pull/413)
DAPR_GRPC_PORT
config, now and in the future?
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?