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 <t...@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 < > 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. > > > -- Regards, Ashwin.
