apex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ashwin Chandra Putta <ashwinchand...@gmail.com>
Subject Re: [VOTE] Major version change for Apex Library (Malhar)
Date Fri, 25 Aug 2017 23:42:59 GMT
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