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
