apex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Weise <...@apache.org>
Subject Re: [VOTE] Major version change for Apex Library (Malhar)
Date Sat, 26 Aug 2017 17:05:25 GMT
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.
> > >
> >
>

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