Mailing-List: contact dev-help@apex.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@apex.apache.org
MIME-Version: 1.0
In-Reply-To: <CAKt=akEb9yjmAKV7j5VK6vxKxfJnOdYz2ZvZLfkeXLacGqm+ug@mail.gmail.com>
References: <CA+5xAo353bk5D=xSLvVwLXK_5vWwSW4u9qxjJO_AWhf=XacY_w@mail.gmail.com>
 <CA+QE8bf_c_Ds+jd_hzK5OAxcOycCqHYcm=ut3Z=zieoN7rdjWw@mail.gmail.com>
 <CA+5xAo1V+UKc7KB5xvDFtaDEevqkTUL9+abnEOB87uEkuu6OuA@mail.gmail.com>
 <CA+QE8beVN8QfyoLq1Z1q-T_xwWUTAY3ir90x56cLzAxaP=N9WQ@mail.gmail.com>
 <CA+5xAo30iw=oMB8EUkPCLS0HN+6WwZL6_r+uRcmpkrt5EKVpYw@mail.gmail.com>
 <CA+QE8bfYZhKgVzFn_0hTfPWNnQj6oKYvRp9VEXmxuusTf9NE7A@mail.gmail.com>
 <CA+5xAo342_iNaY6iP_ByDPSCec+L7w2=hpgD8qPtR=GUdd5ysw@mail.gmail.com>
 <CAB2ZaZNhZDbW+uiqMn4PM1D4Eg6sCms-GqV6YeivkhydKd8arA@mail.gmail.com> <CAKt=akEb9yjmAKV7j5VK6vxKxfJnOdYz2ZvZLfkeXLacGqm+ug@mail.gmail.com>
From: Yogi Devendra <yogidevendra@apache.org>
Date: Fri, 1 Sep 2017 17:48:40 +0530
Message-ID: <CAHekGF9eVzSmhpmFckceHdjjHJCxKiOcAmjXEUy4T__Y6SJeiQ@mail.gmail.com>
Subject: Re: [VOTE] Major version change for Apex Library (Malhar)
To: dev <dev@apex.apache.org>
Content-Type: multipart/alternative; boundary="089e08233ac4ee251c05581fc20c"
archived-at: Fri, 01 Sep 2017 12:18:46 -0000

--089e08233ac4ee251c05581fc20c
Content-Type: text/plain; charset="UTF-8"

One thing which is not clear to me is: if someone has any contributions
planned for 3.x; will that contribution need 2 different PRs?
If yes, then can we avoid this by giving sufficient time for the community
to prepare for this change?

-1 for immediate release.
-1 for immediate separation for 3.x, 4.x.
+0 for doing this after announcing some cooling period.

~ Yogi

On 1 September 2017 at 17:32, Priyanka Gugale <priyag@apache.org> wrote:

> Apologies for being late in discussions. I wanted to understand one thing.
> As Thomas mentioned some of our operators are not matured enought or lacks
> operability. Do we know if such operators need any backword incompatible
> changes? e.g. modification to api etc? Do we have plan to promote operators
> from Evolving to Stable during major version change? I think we should
> think it through. We should list down all possible backword incompatible
> changes, and then cut the release. Let's give sometime to developers to
> come up with such issues in a given time window. A sudden change in major
> version doesn't give us enough time to identify and address all such issues
> and we may warrent one more major version change shortly.
>
> I will propose let's keep this open for sometime and we focus on
> identifying changes which should go in next major version and then go for
> it.
>
> -1 for immediate release or even making release branch now.
>
> -Priyanka
>
> On Fri, Sep 1, 2017 at 11:41 AM, Milind Barve <milindb@gmail.com> wrote:
>
> > Hi
> >
> > First of all my apologies for voting late. However, I will still do it
> > since the mail says the vote would remain open for *at least* 72 hours :)
> > I believe the objective is to do the right things rightly.
> >
> > Moving to a new version is something that is a part of any product
> > lifecycle. While doing so, what is taken into account is -
> >
> > 1. What value the proposed changes are adding to the product.
> > 2. Are the changes big enough to warrant a major version change
> > 3. How big a disruption would it cause to the existing users or dependent
> > products
> > 4. Is enough of a heads up and time given to the users/dependent products
> > to plan for the changes being introduced
> >
> > There could be other factors as well, but I think the above are the most
> > critical ones.
> >
> > As regards the proposed changes, I don't think they satisfy either of the
> > above criteria (expect may be #2 - which is a purely engg. decision)
> >
> > Given the changes proposed,
> >
> > 1. It is going to break the backward compatibility.
> > 2. This is a disruptive change which is going to have existing users plan
> > for and make changes in their product(s). They cannot move to 4.0 without
> > making these changes.
> > 3. Don't think enough of a heads up has been giving to achieve what the
> > users will have to do. As an industry standard, a heads up for at least 2
> > releases is given before the change happens.
> >
> > Due to the above reasons, I am voting a -1
> >
> > Regards,
> >
> > On Sat, Aug 26, 2017 at 10:35 PM, Thomas Weise <thw@apache.org> wrote:
> >
> > > Being against something is not a valid reason. I also want to repeat a
> > > point made earlier regarding discussion style:
> > >
> > > To facilitate a constructive, continuous discussion and make progress,
> it
> > > is necessary that participants take into account what was already
> > > addressed. A few folks that never participated in the discussions
> leading
> > > to this vote don't make or don't want to make that effort.
> > >
> > > The list of functional features added by a release is determined when
> the
> > > release comes out, not before work starts. Furthermore, unless you own
> a
> > > crystal ball, you won't know what contributors decide to take up in the
> > > future, as that's entirely up to them.
> > >
> > > The reason to start a major release line is to enable breaking changes,
> > as
> > > stated in the previous response. The top issues on my list don't
> include
> > > functional feature, but overall lack of consistency, modularity, too
> many
> > > operators that lack operability and maturity, that have not been
> designed
> > > to be production ready and those issues make it just very hard for
> users
> > to
> > > find what is useful.
> > >
> > > New features are added from time to time. You can look at past release
> > > notes and you can also get some forward looking idea by following
> > > discussions and pull requests. One of the things I would hope to see
> > added
> > > is the Python support, Kudu connectors and I would also hope to see
> > changes
> > > to the high level Java API, SQL (windowing) and support for watermarks
> > and
> > > batch demarcation in the existing operators. However, discussion of
> these
> > > isn't relevant to this vote thread.
> > >
> > >
> > > On Fri, Aug 25, 2017 at 6:12 PM, Ashwin Chandra Putta <
> > > ashwinchandrap@gmail.com> wrote:
> > >
> > > > I am not against a new major version. I am against the reason for it.
> > > > Please include a list of functional feature set in the vote for 4.0,
> > not
> > > > just package name changes.
> > > >
> > > > Regards,
> > > > Ashwin.
> > > >
> > > > On Aug 25, 2017 5:02 PM, "Thomas Weise" <thw@apache.org> wrote:
> > > >
> > > > > Always welcome. But before you go.. What do you mean by rigged?
> Your
> > > > vote?
> > > > > ;)
> > > > >
> > > > > Why do I get the impression someone could be pulling strings to
> stop
> > a
> > > > new
> > > > > major version after the changes were discussed for such a long
> time?
> > > > >
> > > > > Why not let the community continue development, it does not prevent
> > > > anyone
> > > > > from continuing 3.x line. That's what versioning and branching are
> > > there
> > > > > for.
> > > > >
> > > > > Thomas
> > > > >
> > > > >
> > > > > On Fri, Aug 25, 2017 at 4:42 PM, Ashwin Chandra Putta <
> > > > > ashwinchandrap@gmail.com> wrote:
> > > > >
> > > > > > Haha I missed your personal attacks Thomas. Love it! This voting
> > > thread
> > > > > is
> > > > > > rigged, I am out :)
> > > > > >
> > > > > > Anyway - as a user when a project announces a new major version
> - I
> > > > would
> > > > > > expect it to include some major features. I stand by my vote
> until
> > we
> > > > > > associate and list some major features with the major version
> > > upgrade.
> > > > > >
> > > > > > Regards,
> > > > > > Ashwin.
> > > > > >
> > > > > > On Fri, Aug 25, 2017 at 3:54 PM, Thomas Weise <thw@apache.org>
> > > wrote:
> > > > > >
> > > > > > > Welcome back to the mailing list (it has been 6 months
> according
> > to
> > > > the
> > > > > > > archive?). The topic seems to be important enough, so hopefully
> > you
> > > > had
> > > > > > the
> > > > > > > chance to review the related discussion threads as these
> already
> > > > > address
> > > > > > > some of what repeats here?
> > > > > > >
> > > > > > > On Fri, Aug 25, 2017 at 2:00 PM, Ashwin Chandra Putta <
> > > > > > > ashwinchandrap@gmail.com> wrote:
> > > > > > >
> > > > > > > > I agree that it makes the project consistent to have the
> > package
> > > > > names
> > > > > > > > changed to org.apache.apex. However, it seems like an
> > unnecessary
> > > > > > > overhead
> > > > > > > > to make a major version change for just changing package
> > names. I
> > > > may
> > > > > > be
> > > > > > > > wrong but is there a major feature set in the proposed vote
> > that
> > > > > deems
> > > > > > > for
> > > > > > > > a major version change? The current package names do not
> affect
> > > any
> > > > > > users
> > > > > > > > in functionality - I would recommend making the package name
> > > change
> > > > > in
> > > > > > a
> > > > > > > > 4.0 branch but decide on major version change based on
> feature
> > > set
> > > > > > > > supporting it.
> > > > > > > >
> > > > > > >
> > > > > > > Already discussed. Major version change is for ability to make
> > > > backward
> > > > > > > incompatible changes, including but not limited to package
> names.
> > > New
> > > > > > > features have been added, they did not require a new major
> > version.
> > > > > > >
> > > > > > >
> > > > > > > >
> > > > > > > > As for 1.0, it seems weird to go back in version. I do not
> > agree
> > > > that
> > > > > > > just
> > > > > > > > because some operators have @evolving tag it means the malhar
> > > > library
> > > > > > is
> > > > > > > > not mature. Many applications are in production using the
> > current
> > > > > > malhar
> > > > > > > > operators - that speaks about maturity.
> > > > > > > >
> > > > > > >
> > > > > > > It may look "weird" to you to go to 1.0, it may also look weird
> > to
> > > > > others
> > > > > > > (including users) to find
> > > > > > > a library at 3.x that is full of evolving code. Based on the
> code
> > > > > changes
> > > > > > > that are made, not just due to the @Evolving annotations that
> > allow
> > > > > such
> > > > > > > changes to occur.
> > > > > > >
> > > > > > > As for "many applications are in production", that is of course
> > > > > > subjective
> > > > > > > but I remember as you should that whenever you want to use one
> of
> > > the
> > > > > > > allegedly "mature" operators, fixes need to be made to them,
> > > > sometimes
> > > > > > for
> > > > > > > very basic issues. At other times, it requires major changes to
> > > such
> > > > > > > operators or they need to be implemented in a different way
> > > > altogether.
> > > > > > > That's not what I would expect when using a dependency
> versioned
> > at
> > > > 3.x
> > > > > > >
> > > > > > >
> > > > > > > > Until there is a major feature set supporting a major version
> > > > > upgrade,
> > > > > > > here
> > > > > > > > is my vote:
> > > > > > >
> > > > > > >
> > > > > > > > -1 for major version change to 4.0 just for package name
> > changes
> > > > and
> > > > > > > > cleanup activities
> > > > > > > > -1 for major version change to 1.0
> > > > > > > > +1 to still make package name changes in a 4.0 branch and
> wait
> > > for
> > > > > > major
> > > > > > > > version change to 4.0 until we have a major feature set
> > > supporting
> > > > > it.
> > > > > > > >
> > > > > > > >
> > > > > > > The place to start major version development according to the
> > > > branching
> > > > > > > model that this project follows is master. Development takes
> > place
> > > > over
> > > > > > > time and a release is made when the community decides so, it
> is a
> > > > > > separate
> > > > > > > decision.
> > > > > > >
> > > > > > > I would consider this vote invalid because it is based on
> invalid
> > > > > > > assumptions about the code maturity/stability in the library
> and
> > > does
> > > > > not
> > > > > > > provide a reason to not make the change.
> > > > > > >
> > > > > > >
> > > > > > > > Regards,
> > > > > > > > Ashwin.
> > > > > > > >
> > > > > > > > On Mon, Aug 21, 2017 at 6:39 PM, Thomas Weise <
> thw@apache.org>
> > > > > wrote:
> > > > > > > >
> > > > > > > > > This is to formalize the major version change for Malhar
> > > > discussed
> > > > > in
> > > > > > > > [1].
> > > > > > > > >
> > > > > > > > > There are two options for major version change. Major
> version
> > > > > change
> > > > > > > will
> > > > > > > > > rename legacy packages to org.apache.apex sub packages
> while
> > > > > > retaining
> > > > > > > > file
> > > > > > > > > history in git. Other cleanup such as removing deprecated
> > code
> > > is
> > > > > > also
> > > > > > > > > expected.
> > > > > > > > >
> > > > > > > > > 1. Version 4.0 as major version change from 3.x
> > > > > > > > >
> > > > > > > > > 2. Version 1.0 with simultaneous change of Maven artifact
> IDs
> > > > > > > > >
> > > > > > > > > Please refer to the discussion thread [1] for reasoning
> > behind
> > > > both
> > > > > > of
> > > > > > > > the
> > > > > > > > > options.
> > > > > > > > >
> > > > > > > > > Please vote on both options. Primary vote for your
> preferred
> > > > > option,
> > > > > > > > > secondary for the other. Secondary vote can be used when
> > > counting
> > > > > > > primary
> > > > > > > > > vote alone isn't conclusive.
> > > > > > > > >
> > > > > > > > > Vote will be open for at least 72 hours.
> > > > > > > > >
> > > > > > > > > Thanks,
> > > > > > > > > Thomas
> > > > > > > > >
> > > > > > > > > [1]
> > > > > > > > > https://lists.apache.org/thread.html/
> bd1db8a2d01e23b0c0ab98a
> > > > > 785f6ee
> > > > > > > > > 9492a1ac9e52d422568a46e5f3@%3Cdev.apex.apache.org%3E
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > >
> > > > > > > > Regards,
> > > > > > > > Ashwin.
> > > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > >
> > > > > > Regards,
> > > > > > Ashwin.
> > > > > >
> > > > >
> > > >
> > >
> >
> >
> >
> > --
> > ~Milind bee at gee mail dot com
> >
>

--089e08233ac4ee251c05581fc20c--