Code style & backwards compatiblity

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

Hi,

looking at Processors I often see things (e.g. internal state) are
protected, public or package private that really shouldn't/needn't be. A
few years ago I tried to change one of those and was told that others might
rely upon and I can't change it for backwards compatibility reasons.

I've now stumbled across this again and am wondering: Is there an official
policy somewhere? I looked at the Developer section of the wiki but
couldn't find anything obvious.

If those things really can't be changed it'd mean that only in NiFi 2.x
changes like this can come in.

I guess this ties into the Extension Registry and separate versions of
processors & NiFi etc.

Cheers,
Lars

Re: Code style & backwards compatiblity

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

Thanks.

This ties in to your answer on RecordReader etc.
There's a chance I missed it but I believe those things (e.g. nifi-api is
meant to be backwards compatible, other parts are not) are not documented
anywhere.
It'd be good to have that in my opinion.
I can put it on my todo list if others agree that this would be worthwhile.

Yes, something specific last week triggered this but I can't remember what
to be honest.

Lars

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

> I think it really comes down to a case by case basis. Generally code
> that is in a processor, or in a specific NAR, is not usually meant to
> be shared or extended from, so the best practice would be to move code
> like that into utility modules in
> nifi-nar-bundles/nifi-extension-utils so that it can be shared across
> many processors.
>
> Did you have any specific changes to processors that you were thinking of?
>
> On Fri, Apr 5, 2019 at 11:33 AM Lars Francke <la...@gmail.com>
> wrote:
> >
> > Hi,
> >
> > looking at Processors I often see things (e.g. internal state) are
> > protected, public or package private that really shouldn't/needn't be. A
> > few years ago I tried to change one of those and was told that others
> might
> > rely upon and I can't change it for backwards compatibility reasons.
> >
> > I've now stumbled across this again and am wondering: Is there an
> official
> > policy somewhere? I looked at the Developer section of the wiki but
> > couldn't find anything obvious.
> >
> > If those things really can't be changed it'd mean that only in NiFi 2.x
> > changes like this can come in.
> >
> > I guess this ties into the Extension Registry and separate versions of
> > processors & NiFi etc.
> >
> > Cheers,
> > Lars
>

Re: Code style & backwards compatiblity

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

I think it really comes down to a case by case basis. Generally code
that is in a processor, or in a specific NAR, is not usually meant to
be shared or extended from, so the best practice would be to move code
like that into utility modules in
nifi-nar-bundles/nifi-extension-utils so that it can be shared across
many processors.

Did you have any specific changes to processors that you were thinking of?

On Fri, Apr 5, 2019 at 11:33 AM Lars Francke <la...@gmail.com> wrote:
>
> Hi,
>
> looking at Processors I often see things (e.g. internal state) are
> protected, public or package private that really shouldn't/needn't be. A
> few years ago I tried to change one of those and was told that others might
> rely upon and I can't change it for backwards compatibility reasons.
>
> I've now stumbled across this again and am wondering: Is there an official
> policy somewhere? I looked at the Developer section of the wiki but
> couldn't find anything obvious.
>
> If those things really can't be changed it'd mean that only in NiFi 2.x
> changes like this can come in.
>
> I guess this ties into the Extension Registry and separate versions of
> processors & NiFi etc.
>
> Cheers,
> Lars