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 00:01:59 GMT
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/bd1db8a2d01e23b0c0ab98a785f6ee
> > > > 9492a1ac9e52d422568a46e5f3@%3Cdev.apex.apache.org%3E
> > > >
> > >
> > >
> > >
> > > --
> > >
> > > Regards,
> > > Ashwin.
> > >
> >
>
>
>
> --
>
> Regards,
> Ashwin.
>

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