+1 to David Jencks. i raised a while ago but coul not start doing anything on it. https://camel.465427.n5.nabble.com/deprecated-components-by-which-version-of-camel-td5842700.html it would be a good addition while playing around with models.
On Mon, Apr 6, 2020 at 5:17 PM David Jencks <david.a.jen...@gmail.com> wrote: > I’ve been looking at the tables of components, data formats, etc in the > website and wondering if it would be useful to show "version deprecated > since” rather than just the deprecated flag. Is this information even > available? Does this seem like a good idea? I expect to propose a > different way to construct the tables shortly. IIUC these tables are > constructed from the same info source as the catalog. > > David Jencks > > > On Apr 6, 2020, at 5:26 AM, Claus Ibsen <claus.ib...@gmail.com> wrote: > > > > On Mon, Apr 6, 2020 at 11:50 AM Peter Palaga <ppal...@redhat.com > <mailto:ppal...@redhat.com>> wrote: > >> > >> 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. > >> > > > > Yeah actually this is better description of the purpose, so its per > release > > and dont necessary warrant the same level in the next release. > > > > And this also makes sense for some users to have a hint/warn reported > > if they use a non-stable component. > > For example with some tooling to report this, or some flag we can turn > > on|off in Camel to report this on startup. > > > > > >>> 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? > >> > > > > Yes Camel Quarkus is the only project that has this knowledge. And it > > also have some components that are only there, > > such as the camel-cute component. > > > > So if Camel K wants to know which extensions are native or not, then > > it should use the camel-quarkus catalog. > > > > This is the game, same for OSGi with the camel-karaf catalog, and for > > Spring Boot with the camel-spring-boot catalog. > > > > > >>> 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 > >> > > > > > > -- > > Claus Ibsen > > ----------------- > > http://davsclaus.com <http://davsclaus.com/> @davsclaus > > Camel in Action 2: https://www.manning.com/ibsen2 < > https://www.manning.com/ibsen2> >
