IMO, I'd mark a component as `stable` after a few Camel releases that include the component, no idea how many, but this at least gives me the hint that the component is stable enough for this use. That means, a new component that is being added to camel code base, I'd mark it as `Preview`. At least in that sense, it can make sense here.
Regards, Omar On Mon, Apr 6, 2020 at 9:59 AM Claus Ibsen <claus.ib...@gmail.com> 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. > > 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. > > > > 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> > > > > > -- > Claus Ibsen > ----------------- > http://davsclaus.com @davsclaus > Camel in Action 2: https://www.manning.com/ibsen2 >
