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 < ashwinchand...@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 <t...@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. >
