Can we define some criteria for deciding when to consider operator as @Stable? Yes, we should follow Hadoop's example and formalize some criteria.
[It would be difficult for an open source project to track which user is using which operators. So, above strategy may not work. ] Hadoop is an open source project which actually created these annotations and it's widely used. I think any new development takes time to become stable. If the operators are NOT marked as @Stable, users will know that when they upgrade backward compatibility may be broken. I think it has the same affect of marking every new operator/class as @Evolving. The benefit of checking semantic versioning of "Stable" operators is that they are currently fewer in number and IMO easy to manage and new development will be implicitly "Evolving". Chandni On Sun, Dec 13, 2015 at 9:11 PM, Yogi Devendra <[email protected]> wrote: > When to mark certain operator as @Stable is not clearly defined. > > Can we define some criteria for deciding when to consider operator as > @Stable? > > For example one criteria could be, if operator is running for >1 year in > production environment for some user. Can we come with some strategy like > this? > [It would be difficult for an open source project to track which user is > using which operators. So, above strategy may not work. ] > > ~ Yogi > > On 14 December 2015 at 05:42, Timothy Farkas <[email protected]> wrote: > > > +1 > > On Dec 13, 2015 4:08 PM, "Chandni Singh" <[email protected]> > wrote: > > > > > Hi, > > > > > > In Malhar there are relatively smaller number of operators that we > use > > in > > > our demo applications, customer applications, POCs etc that are mature. > > > > > > The library is cluttered with operators especially in lib/util, > lib/algo, > > > lib/math packages which can be cleaned up by either removing them or > > > improving them but that breaks semantic versioning. > > > > > > When we add new operators/utilities it takes certain time for them to > > > mature. Japicmp doesn't help because it doesn't honor @Evolving > @Unstable > > > annotations for now. > > > > > > I wanted to propose that we add an annotation, let's say, re-use > hadoop's > > > @Stable and mark the operators which are stable with it and perform > > semver > > > check on just these operators. > > > > > > The 0.7.0 version of japi cmp has the support for inclusions (as well > as > > > exclusions) based on annotations. > > > > > > Here is the info: > > > https://github.com/siom79/japicmp/issues/88 > > > > > > The reason I am inclined to the inclusion approach is that there are > > > relatively smaller number of operators which IMO are stable. A lot of > > them > > > aren't. > > > So instead of going and marking so many as Evolving, we will mark > > > relatively few of them as stable. > > > > > > Also new development can be facilitated by this. We wouldn't have to > add > > > @Evolving to everything which is new. Instead we will mark it @Stable > > when > > > it is. > > > > > > Please let me know what you think? > > > > > > Thanks, > > > Chandni > > > > > >
