Hi All, Thanks for the input! I have created a general Jira case [1] comments or extra tasks can be added to this case.
As Nicolas stated, the problem can currently be solved by using the categories. Using the deprecated category will give a clear indication in the GUI that the transform is no longer supported For new actions or transforms the best way to do it currently would be to use the BaseTransform.Category.Experimental or create a new category Cheers, Hans [1] https://issues.apache.org/jira/browse/HOP-2424 On Thu, Jan 14, 2021 at 9:50 PM Brandon Jackson <[email protected]> wrote: > I like the idea of these annotations. It might be interesting if we could > collect and emit telemetry data about steps used too. > I could imagine scanning my projects to get an idea of how conformant it is > with current standards. > If pipelines are in production; there is some implied engineering effort to > switch out deprecated steps to maintained steps that we would want to > enable ETL designers with. > The annotations will help a lot; but what should the policy be. Next > release deprecated plugins are gone; or after a major release? > > What criteria positions a plugin for deprecation? > > Brandon > > > > On Thu, Jan 14, 2021 at 9:25 AM Sergio Ramazzina (SERASOFT) < > [email protected]> wrote: > > > Below my comments: > > > > Il 14/01/2021 10:34, Matt Casters ha scritto: > > > Great ideas. Having indicators for users to let them know the state of > a > > > plugin is a great way of going about things I think. > > > That being said I think that terms like "production ready" are > ambiguous > > > and rather arbitrary. > > Yes Matt you are right I misused that term, it was better to say > > something like just "stable". > > > Perhaps we can put some additional requirements on that? > > > > > > Perhaps we should require for "production ready" plugins the following > to > > > be available: > > > - Documentation > > > - Integration test(s) > > > - Sample(s) > > > > > > Perhaps this is also more an indication of stability, rather than > > > production readiness? > > > If that's the case we come to something like this: > > > > > > * *Stable* : Documented, multiple integration tests (IT) & Samples > > > * *Beta* : first introduced version, no IT, docs or samples > > > * *Alpha* : experimental > > > * *Deprecated* : will be removed in a future version > > > > > > For example, right now only a few transforms would fall under Stable. > > > If we could set up rules and definitions like this I think it would > > really > > > help us as well to assess how far along we are towards our goal of > > hitting > > > a 1.0 with only "stable" plugins in Hop. > > > > Would be nice to have a mechanism to check that all of the required > > parts (Documentation, Integrations test, Samples) are present and that > > integration tests passed without any problems and basing on the results > > of these checks, flags the Transform as Stable, Beta and Alpha > > automatically. Deprecation is the only thing requires to be managed > > manually > > > > Cheers > > > > S > > > > >
