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>
