[
https://issues.apache.org/jira/browse/NIFI-1373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15426981#comment-15426981
]
Joseph Witt commented on NIFI-1373:
-----------------------------------
Have evaluated the mechanics of this deeper. There was work done during the
1.0 release cycle to more cleanly separate out the nifi-api from other
internally useful APIs. As a result the only thing at this time that really
should be labelled @InterfaceAudience.Public and @InterfaceStability.Stable is
the classes within nifi-api. Rather than adding a new dependency throughout
the codebase I have documented this here and will close the ticket (without
specific version) as resolved.
We could later explore more formal mechanisms whereby we introduce the yetus
annotations into the codebase because we're going to do things like warn users
who extend from classes they shouldn't and so on.
Here is that link:
https://cwiki.apache.org/confluence/display/NIFI/Version+Scheme+and+API+Compatibility
> Annotate all classes to indicate their API stability and intended audience
> --------------------------------------------------------------------------
>
> Key: NIFI-1373
> URL: https://issues.apache.org/jira/browse/NIFI-1373
> Project: Apache NiFi
> Issue Type: Task
> Components: Core Framework, Core UI, Extensions
> Reporter: Joseph Witt
> Assignee: Joseph Witt
>
> Sean Busbey and Tony Kurc have pointed out the need to document the intended
> audience and stability of the APIs. This is very necessary as we need to be
> able to make changes and be fluid where intended and extremely strict to
> compatibility where intended. Presently with things being unmarked it can be
> ambiguous for those not deeply familiar with the api and codebase.
> By leveraging the annotations from Apache Yetus we can resolve this
> discrepancy across the codebase:
> http://yetus.apache.org/documentation/0.1.0/audience-annotations-apidocs/
> To Do:
> 1) Go through entire codebase and tag classes appropriate with Yetus
> annotations.
> 2) Update our versioning guidance to reflect that our major/minor/incremental
> model only applies to those classes which are tagged as stable/etc.. We
> should be able to safely maneuver and update internal APIs without any risks
> to compatibility. Through discussions things should become more stable and
> if we find folks wanting to extend/alter things which we didn't have listed
> as stable then those are great things to start discussion on. Right now
> we're too hamstrung by thinking we have to hold onto everything.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
