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" <t...@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 < > ashwinchand...@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 <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/bd1db8a2d01e23b0c0ab98a > 785f6ee > > > > > 9492a1ac9e52d422568a46e5f3@%3Cdev.apex.apache.org%3E > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > Regards, > > > > Ashwin. > > > > > > > > > > > > > > > -- > > > > Regards, > > Ashwin. > > >
