Re: dealing with a breaking change

2022-10-08 Thread Mark Payne
I think the best solution here is definitely to make use of dependent properties. We would leave the existing “Maximum Rate” property as-is, except make it depend on the Rate Control Criteria being one of the currently existing values. And then we’d add a new allowable value for the Rate Control

Re: dealing with a breaking change

2022-10-08 Thread Mark Bean
There was a reason I left "new processor" as the last option. In my opinion, it's the least desirable - but honestly, it's the easiest. Still... Deprecating the property isn't really appropriate here because the property remains. It's just that its behavior (allowable values) changes. Or so I thou

Re: dealing with a breaking change

2022-10-08 Thread Joe Witt
Phil As we approach time for some house cleaning in a nifi 2.0 world such a model/idea will be important for sure. Mark Breaking old behavior would be problematic. And I think youre right that only sorta clunky options exist with the current one. I was thinking you could do something with depe

Re: dealing with a breaking change

2022-10-08 Thread Phil H
It might be too much to do prior to solving this problem, but for the general case, but could NiFi benefit from a @Depricated annotation (or similar) on PropertyDescriptor. This could be read only, requiring the admin to change to the new property. Alternatively, the deprecated property could be h