apex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tushar Gosavi <tus...@datatorrent.com>
Subject Re: Enable semantic versioning only for specific operators in Malhar
Date Mon, 14 Dec 2015 06:46:12 GMT
+1
The new operators added will most likely to undergo change frequently until
they become stable.

- Tushar.


On Mon, Dec 14, 2015 at 12:05 PM, Siyuan Hua <siyuan@datatorrent.com> wrote:

> +1
>
> On Sun, Dec 13, 2015 at 10:01 PM, Yogi Devendra <yogidevendra@apache.org>
> wrote:
>
> > I am not against the Idea of using @Stable instead of marking every new
> > @Evolving. I agree that, it would convenient to have @Stable.
> >
> > Just raised the point which needs further discussion, so that we get
> > suggestions from the mentors and community.
> >
> > ~ Yogi
> >
> > On 14 December 2015 at 11:23, Chandni Singh <chandni@datatorrent.com>
> > wrote:
> >
> > > 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 <
> yogidevendra@apache.org>
> > > 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 <tim@datatorrent.com>
> > > wrote:
> > > >
> > > > > +1
> > > > > On Dec 13, 2015 4:08 PM, "Chandni Singh" <chandni@datatorrent.com>
> > > > 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
> > > > > >
> > > > >
> > > >
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message