Stability of RecordReader et. al.

[Lars Francke <la...@gmail.com>]

Hi,

a customer stumbled upon these comments in RecordSetWriterFactory,
RecordReader, WriteResult and RecordSetWriter:

"PLEASE NOTE: This interface is still considered 'unstable' and may change
in a non-backward-compatible manner between minor or incremental releases
of NiFi."

Is this still true? I found a Mailing list Thread from ~2018 claiming it's
been stable for a while.

If so: Would you mind me creating a Jira & Pull Request to remove those
comments? They can be confusing.

Cheers,
Lars

Re: Stability of RecordReader et. al.

[Lars Francke <la...@gmail.com>]

Hi Bryan,

thank you for the detailed explanation. I agree with you re: backwards
compatibility.

In that case I'll create a patch next week.

Cheers,
Lars

On Fri, Apr 5, 2019 at 6:31 PM Bryan Bende <bb...@gmail.com> wrote:

> Hi Lars,
>
> I think the issue is that the classes you referenced are not formally
> part of nifi-api, they are technically part of a controller service
> API. So the reference to 'unstable' doesn't really mean that record
> processing itself is unstable, it refers more to the API guarantees
> that are being made for those people developing custom components.
>
> I believe that our stance is that we only guarantee backwards
> compatibility on minor releases for stuff in nifi-api, although we do
> generally strive to not break controller service APIs if possible.
>
> As an example, we would never put out a 1.x release that change a
> method signature in the Processor interface since this comes from
> nifi-api and impacts all existing processors (both those that are part
> of the nifi distribution, as well as any custom processors people have
> developed).
>
> We could in theory put out a 1.x release that changes a method
> signature in RecordReader since that is not part of nifi-api, and
> anyone who has implemented a processor that uses a record reader would
> have to update their code to adjust to changes. In practice we would
> try to avoid this if possible by introducing new methods with default
> implementations deprecating old methods.
>
> So long story short... personally I think it is fine to remove those
> statements, but I wanted to highlight that technically I believe a
> controller service API could be changed in a non-backward compatible
> manner even without those statements, but maybe others have different
> thoughts.
>
> -Bryan
>
> On Fri, Apr 5, 2019 at 11:21 AM Lars Francke <la...@gmail.com>
> wrote:
> >
> > Hi,
> >
> > a customer stumbled upon these comments in RecordSetWriterFactory,
> > RecordReader, WriteResult and RecordSetWriter:
> >
> > "PLEASE NOTE: This interface is still considered 'unstable' and may
> change
> > in a non-backward-compatible manner between minor or incremental releases
> > of NiFi."
> >
> > Is this still true? I found a Mailing list Thread from ~2018 claiming
> it's
> > been stable for a while.
> >
> > If so: Would you mind me creating a Jira & Pull Request to remove those
> > comments? They can be confusing.
> >
> > Cheers,
> > Lars
>

Re: Stability of RecordReader et. al.

[Bryan Bende <bb...@gmail.com>]

Hi Lars,

I think the issue is that the classes you referenced are not formally
part of nifi-api, they are technically part of a controller service
API. So the reference to 'unstable' doesn't really mean that record
processing itself is unstable, it refers more to the API guarantees
that are being made for those people developing custom components.

I believe that our stance is that we only guarantee backwards
compatibility on minor releases for stuff in nifi-api, although we do
generally strive to not break controller service APIs if possible.

As an example, we would never put out a 1.x release that change a
method signature in the Processor interface since this comes from
nifi-api and impacts all existing processors (both those that are part
of the nifi distribution, as well as any custom processors people have
developed).

We could in theory put out a 1.x release that changes a method
signature in RecordReader since that is not part of nifi-api, and
anyone who has implemented a processor that uses a record reader would
have to update their code to adjust to changes. In practice we would
try to avoid this if possible by introducing new methods with default
implementations deprecating old methods.

So long story short... personally I think it is fine to remove those
statements, but I wanted to highlight that technically I believe a
controller service API could be changed in a non-backward compatible
manner even without those statements, but maybe others have different
thoughts.

-Bryan

On Fri, Apr 5, 2019 at 11:21 AM Lars Francke <la...@gmail.com> wrote:
>
> Hi,
>
> a customer stumbled upon these comments in RecordSetWriterFactory,
> RecordReader, WriteResult and RecordSetWriter:
>
> "PLEASE NOTE: This interface is still considered 'unstable' and may change
> in a non-backward-compatible manner between minor or incremental releases
> of NiFi."
>
> Is this still true? I found a Mailing list Thread from ~2018 claiming it's
> been stable for a while.
>
> If so: Would you mind me creating a Jira & Pull Request to remove those
> comments? They can be confusing.
>
> Cheers,
> Lars