Fabian took another look into the interface stability PR for flink-core.
There are the following issues which we need to decide upon:
1) The "ExecutionMode" class name is misleading because its for batch-jobs
only.
I suggest to make the ExecutionMode class an "@Experimental" interface
(and the E
I've also had a look. +1 to merge from my side.
On Tue, Dec 15, 2015 at 3:27 PM, Robert Metzger wrote:
> The PR has been open for a while, Stephan, Aljoscha and Henry looked over
> it and I've addressed all comments by them:
> https://github.com/apache/flink/pull/1427
>
> I would like to merge th
The PR has been open for a while, Stephan, Aljoscha and Henry looked over
it and I've addressed all comments by them:
https://github.com/apache/flink/pull/1427
I would like to merge the pull request adding the "flink-annotations"
module and annotating all classes in "flink-core" soon (say, next 24
I left out the classes in memory except for the Input/Output views.
Or course, we should try to minimize the stable classes, but user programs
get a lot of extension points in Flink ;)
I've opened a pull request with my current suggestion:
https://github.com/apache/flink/pull/1426
On Tue, Dec 1
Thanks for the explanation. I was just wondering how you approached
the problem. Going through class-by-class makes sense.
Not sure whether we want to make "org.apache.flink.core.memory" and
"org.apache.flink.api.common.distributions" stable interfaces. I would
think these qualify more as experime
Hi Max,
classes in flink-scala are annotated as well, and its also in the list :)
I considered classes in flink-core, flink-runtime, flink-scala,
flink-streaming-java, flink-streaming-scala,
flink-connector-kafka, flink-connector-filesystem, flink-avro and
flink-hadoop-compatibility.
I think ther
Thank for your getting us started on annotating the API. The list
looks good so far. I have the feeling it could even be extended a bit.
Just curious, how did you choose which classes you annotate? Did you
go through all the classes in flink-core, flink-java, and
flink-clients Maven projects?
What
Okay, I'll introduce an annotation for experimental interfaces and I'll
make everything we have deprecated experimental.
On Fri, Nov 27, 2015 at 10:40 AM, Aljoscha Krettek
wrote:
> I still think we also need an annotation to mark public interfaces as
> experimental. For example for the windowing
I still think we also need an annotation to mark public interfaces as
experimental. For example for the windowing/triggers I would like to use that.
> On 25 Nov 2015, at 01:23, Robert Metzger wrote:
>
> Thank you Nick. I'll look into the check_compatiblilty.sh script to see
> which tools are use
Thank you Nick. I'll look into the check_compatiblilty.sh script to see
which tools are used.
I think finding breaking API changes immediately is a better process then
reworking the APIs before a release.
As you can see from my email response times (2 days since your email), I'm
probably too overl
>
> Do you know if Hadoop/HBase is also using a maven plugin to fail a build on
> breaking API changes? I would really like to have such a functionality in
> Flink, because we can spot breaking changes very early.
I don't think we have maven integration for this as of yet. We release
managers run
Sorry for delaying this discussion a bit. I was busy fixing bugs in 0.10.0
;)
@Nick: Thank you for the pointer to Yetus. I definitively like the idea of
having a central project for all the Hadoop-related project tooling.
Do you know if Hadoop/HBase is also using a maven plugin to fail a build on
+1 for some way of declaring public interfaces as experimental.
> On 10 Nov 2015, at 22:24, Stephan Ewen wrote:
>
> I think we need anyways an annotation "@PublicExperimental".
>
> We can make this annotation such that it can be added to methods and can
> use that to declare
> Methods in an oth
I think we need anyways an annotation "@PublicExperimental".
We can make this annotation such that it can be added to methods and can
use that to declare
Methods in an otherwise public class (such as DataSet) as experimental.
On Tue, Nov 10, 2015 at 10:19 PM, Fabian Hueske wrote:
> I am not sur
I am not sure if we always should declare complete classes as
@PublicInterface.
This does definitely make sense for interfaces and abstract classes such as
MapFunction or InputFormat but not necessarily for classes such as DataSet
that we might want to extend by methods which should not immediately
Yes, my opinion is that we shouldn't declare the Gelly API frozen yet.
We can reconsider when we're closer to the 1.0 release, but if possible, I
would give it some more time.
-V.
On 10 November 2015 at 21:06, Stephan Ewen wrote:
> I think no component should be forced to be stable. It should b
I think no component should be forced to be stable. It should be an
individual decision for each component, and in some cases even for
individual classes.
@Vasia If you think Gelly should not be declared interface-frozen, then
this is a good point to raise and this should definitely be reflected.
Hi Robert,
thanks for bringing this up!
I generally like the idea, but I wouldn't rush to annotate the Gelly
classes yet. Gelly hasn't had that many users and I'm quite sure we'll find
things to improve as it gets more exposure.
TBH, I think it's quite unfair to force Gelly (also e.g. ML, Table)
For what it's worth, the new Apache Yetus [0] project includes an interface
audience annotations module [1]. We have (or intend to have, if it's not
available yet) tools for validation of public API compatibility across
release versions. For example, here's such a report [2] from a previous
HBase R
Hi everyone,
I would like to bring this discussion back to your attention as we seem to
approach the 1.0 release of Flink.
My suggestion back in January was to annotate all classes, but I think
it'll be more feasible to just annotate public classes.
So how about adding an annotation @PublicInterf
I like the idea. But would love to have different name for the
"LimitedPrivate" to make it easier to distinguish.
How about "Module" or "Package" ?
- Henry
On Wed, Jan 28, 2015 at 1:29 AM, Robert Metzger wrote:
> I think in Hadoop they use LimitedPrivate for the different components of
> the pro
I think in Hadoop they use LimitedPrivate for the different components of
the project.
For example LimitedPrivate("yarn").
Here is a very good documentation on the topic:
https://hadoop.apache.org/docs/stable/hadoop-project-dist/hadoop-common/InterfaceClassification.html
On Tue, Jan 27, 2015 at 3:
I don't get the difference between Private and LimitedPrivate, but
otherwise seems like quite a nice idea.
It will be also good if we can agree upon what these tags actually mean and
add this meaning to the documentation.
2015-01-27 15:46 GMT+01:00 Robert Metzger :
> Hi,
>
> Hadoop has annotatio
Hi,
Hadoop has annotations for tagging the stability and audience of classes
and methods.
Through that, you can have @InterfaceAudience.Public, Private,
LimitedPrivate
and also @InterfaceStability.Evolving, Unstable, and Stable.
I guess there are tools which allow to automatically check if inter
24 matches
Mail list logo
