Hi, thanks Claus for writing this down.
On 06/04/2020 09:58, Claus Ibsen wrote:
Hi Background this PR https://github.com/apache/camel/pull/3698 a) I think it can benefit Camel components if we are able to define what maturity/stability level the component is (find a good name). For example we could the values that other projects uses such as Quarkus and WildFly: Stable, Preview, Experimental However the devil is in the wording. For example does Stable mean that it's stable forever. And that is a NO. A camel component may change between LTS releases, as we want to innovate fast and move on. For example a 3rd party dependency upgrade may cause some changes, or a major upgrade which we want. SB1 to SB2 etc. netty3 -> netty4. And sometimes we created a new component and other times we upgraded the existing component.
My intention was to express runtime stability of a particular release rather than API/ABI stability over time. - I.e. if base64 component is marked as "stable" in release 1.2.3 it means we (the authors) have enough confidence (based on test coverage and/or a low number of known issues or limitations, etc.) to recommend deploying it in production. "Production quality" might be a better term for this. The other value (i took the term "preview") is supposed to be opposite: There are known issues, known limitations, not enough test coverage or the code is simply too new to be confident about its runtime stability.
This marker is assigned to some specific release of a component. If base64 is marked as "stable" in 1.2.3, it does not necessarily imply anything about the future releases. It may (although it would be rather unusual) become "preview" in the future (say, because an early major upgrade of its dependency is instable). It may be removed (after some deprecation period), its configuration may change substantialy, etc. The stability assessment is done only for the given release and nothing else.
b) The second information that may benefit, is whether a component would be compilable for native via graalvm. But at this moment then I think this information is best kept in camel-quarkus as this is where we know whether its fully native or jvm only. So I would keep this information in the camel quarkus catalog only.
Yes, Camel Quarkus will presumably be the only one to have the Native compilation target in its catalog. However, Camel K will leverage that info and thus the common Camel Catalog model should IMO be able to express that state. Having a custom catalog model in Camel Quarkus seems to be impractical for both Camel Quarkus and Camel K. Is that what you propose?
Ad a) We could then store this information about maturity level in the <properties> section of pom.xml where we already store labels, description, and whether its deprecated. <properties> <stability>stable</stability> ... </properties>
No problem with that. The PR linked above checks the @Experimental annotation on component, language, etc. classes and if it is present, it makes the given component "preview". I can remove that.
Thanks, -- Peter
