lburgazzoli commented on issue #5328:
URL: https://github.com/apache/camel-k/issues/5328#issuecomment-2051522307
IMHO, the biggest issue here is that we are mixing up different topics.
As an example, the sentence below, does not seems (to me) right or it at
least is not clear enough:
> I think that, by nature, the traits are quickly evolving in order to add
features, above all when it comes to Kubernetes features. For example, adding a
new Kubernetes feature mostly of the time would require altering the traits
(hence, altering the CRD and possibly breaking compatibility).
The reason why it is not clear, is that it seems to assumes that the APIs
are only composed by the CRDs but in fact, they are the result of the
intersection of what is defined in the CRDs and what it is not, an example of a
non described APIs are the annotations. For such reasons, a change in a trait
can lead to break backward compatibility even if we remove its traits
definition from the CRDs.
So it seems to me that this issue has not so much to do with the APIs per
se, but more about eventually reducing the amount of work to maintain the CRDs,
topic for which I cannot say much since it's been long time since I'm involved
in that. If we move in this direction, we must make crystal clear that this has
**no impact** on the way we deal we the APIs and we **must ensure** that every
change on the traits is then handled as it it were part of the CRDs.
I would really recommend to re-phrase the issue and also include some
pro/cons so we can have a better understanding of the complexity/impacts.
--
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.
To unsubscribe, e-mail: commits-unsubscr...@camel.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
