Hadoop uses this approach to mark API methods as Stable/Unstable/etc. I think the rule of thumb is that Major.Minor.Patch versions correspond to Breaking.Feature.Fix
Sent from my iPhone > On Jan 5, 2016, at 7:01 PM, Tony Kurc <[email protected]> wrote: > > I'm trying to read code on my phone, but It looks like most of those > classes are private. It seems #1 may be the best approach. > > We keep having conversations about moving code around - I'd like to restate > that I'm in favor of annotations on fields and methods to note whether they > are intended extension points or subject to change, which would likely make > this a no-brainer. Has anyone else come to this conclusion? >> On Jan 5, 2016 6:38 PM, "Bryan Bende" <[email protected]> wrote: >> >> If it helps at all, here is a possible refactoring based on making a syslog >> package under org.apache.nifi.processors.standard, and moving the parser >> and event classes there as well: >> >> >> https://github.com/bbende/nifi/tree/NIFI-1273/nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/syslog >> >> >>> On Tue, Jan 5, 2016 at 6:14 PM, Tony Kurc <[email protected]> wrote: >>> >>> Excellent questions, Bryan. I'll give it some thought tonight. >>> >>>> On Tue, Jan 5, 2016 at 11:22 AM, Bryan Bende <[email protected]> wrote: >>>> >>>> All, >>>> >>>> I'm working on NIFI-1273 to add support for the RELP protocol (Reliable >>>> Event Logging Protocol) to the syslog processors. In order to do this >>> I'll >>>> likely have to add at least one more channel reader implementation to >> the >>>> inner classes that already exist in ListenSyslog. I'm starting to think >>>> there might be a bit too much going on in there and it might be easier >> to >>>> manage and understand if the inner classes were moved to regular >> classes. >>>> >>>> If we agree that is a good idea, then the question is where to put >>> them.... >>>> In hindsight it probably would have been better to have a syslog >> bundle, >>>> instead of putting the syslog processors in the >> nifi-standard-processors, >>>> then all of these classes could live there. The processors don't have >> any >>>> special dependencies which is why the standard bundle initially seemed >>> like >>>> a good idea. >>>> >>>> Since we have to be careful of breaking changes, the options I see are: >>>> >>>> 1) Keep the syslog processors in nifi-standard-processors, and put >> these >>>> classes under the util package where SyslogParser and SyslogEvent are. >>>> Maybe create org.apache.nifi.processors.standard.util.syslog to group >>> them >>>> together under util. >>>> >>>> 2) Keep the syslog processors in nifi-standard-processors, but create a >>>> nifi-syslog-utils project in nifi-commons and put all supporting code >>>> there. I doubt that any other parts of NiFi would need to make use of >>> this >>>> artifact, but it would create a nice isolated syslog library. I think >> we >>>> could safely move most of the inner classes there since they are >> private, >>>> but not sure if we can move SyslogParser and SyslogEvent yet since they >>> are >>>> public classes in standard processors. >>>> >>>> 3) Create a syslog bundle with copies of the processors, do all new >> work >>>> there, including NIFI-1273. Mark the existing processors as deprecated >>> and >>>> remove on 1.0. Seems unfortunate to deprecate processors one release >>> after >>>> releasing them, and would force anyone wanting RELP to switch to the >> new >>>> bundle, but seems to be the only way to create a separate bundle if >> that >>> is >>>> what we wanted. >>>> >>>> What do others think about this? >>>> >>>> #1 is obviously the least intrusive and easiest, but I'm not sure it is >>> the >>>> best choice, especially given that we want to move to an extension >>> registry >>>> eventually, and would probably want to break apart some of standard >>>> processors. >>>> >>>> #2 might be a good middle ground. Leaving the processor part for >> another >>>> time. >>>> >>>> -Bryan >>
