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
>
>

Reply via email to