a) I think building on top of sinceVersion is good. b) I don't have strong opinion yet where such information should go. I don't feel native is the right word, I would tend to see this as a kind of platform level support like karaf/spring-boot/camel-k/quarkus-jvm/quarkus-graal/any-concurrent-of-graal.
hth ;) Alex On Mon, Apr 6, 2020 at 10:36 AM Claus Ibsen <claus.ib...@gmail.com> wrote: > On Mon, Apr 6, 2020 at 10:14 AM Omar Al-Safi <o...@oalsafi.com> wrote: > > > > 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. > > > > Yeah but that is also what since version is for, you can see that > today, see the since column, > https://camel.apache.org/components/latest/ > > But yes we could have a default rule in the build tooling so when we > build a release, it would use preview (if no explicit set and that the > component is new, or N-1 release old). > Then we dont need to remember to update all these components manually over > time. > > > > 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 > > > > > > > -- > Claus Ibsen > ----------------- > http://davsclaus.com @davsclaus > Camel in Action 2: https://www.manning.com/ibsen2 >
