astefanutti commented on pull request #1912: URL: https://github.com/apache/camel-k/pull/1912#issuecomment-760754939
> > That is a great improvement! Here are my first feedback: > > ``` > > * I wonder whether the `--operator` is necessary and `kamel version` should just output both client and server versions, similarly to what `kubectl version` does > > ``` > > It was my first choice, but later I realized that the client version is meant to work also "offline". I can rework that part in order to skip the online/offline check and have either the operator version or a message error when disconnected, wdyt? I agree, if that is easy enough, it can print a message that no operator version can be retrieve. It may also happen when no operator is deployment in the current context, or there is no default context. > > > ``` > > * For the compatibility detection, ideally a warning should be displayed when there is an actual compatibility issue. Otherwise, an informative message could be displayed to suggest the user to upgrade. I understand this is more involved, as the information has to be provided by the developers somewhere, plus forward compatibility is an issue. `kubectl` has also already approached the issue by requesting the server, as described in https://kubernetes.io/blog/2020/09/03/warnings/. That being said, `kamel` does not always interact with the operator directly, and we may not want to expose an endpoint for that purpose. So maybe outputting an informative message, for all _online_ commands is an acceptable tradeoff. > > ``` > > This would be nice, though it requires quite a few changes, and during development we must find a way to "mark" when some change is breaking compatibility. I think for the time being an informative message is a good addition to inform the user that if something does not work, it may be because the cli/operator misalignment. I agree. An informative message is an acceptable tradeoff. ---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected]
