Hi First of all my apologies for voting late. However, I will still do it since the mail says the vote would remain open for *at least* 72 hours :) I believe the objective is to do the right things rightly.
Moving to a new version is something that is a part of any product lifecycle. While doing so, what is taken into account is - 1. What value the proposed changes are adding to the product. 2. Are the changes big enough to warrant a major version change 3. How big a disruption would it cause to the existing users or dependent products 4. Is enough of a heads up and time given to the users/dependent products to plan for the changes being introduced There could be other factors as well, but I think the above are the most critical ones. As regards the proposed changes, I don't think they satisfy either of the above criteria (expect may be #2 - which is a purely engg. decision) Given the changes proposed, 1. It is going to break the backward compatibility. 2. This is a disruptive change which is going to have existing users plan for and make changes in their product(s). They cannot move to 4.0 without making these changes. 3. Don't think enough of a heads up has been giving to achieve what the users will have to do. As an industry standard, a heads up for at least 2 releases is given before the change happens. Due to the above reasons, I am voting a -1 Regards, On Sat, Aug 26, 2017 at 10:35 PM, Thomas Weise <t...@apache.org> wrote: > Being against something is not a valid reason. I also want to repeat a > point made earlier regarding discussion style: > > To facilitate a constructive, continuous discussion and make progress, it > is necessary that participants take into account what was already > addressed. A few folks that never participated in the discussions leading > to this vote don't make or don't want to make that effort. > > The list of functional features added by a release is determined when the > release comes out, not before work starts. Furthermore, unless you own a > crystal ball, you won't know what contributors decide to take up in the > future, as that's entirely up to them. > > The reason to start a major release line is to enable breaking changes, as > stated in the previous response. The top issues on my list don't include > functional feature, but overall lack of consistency, modularity, too many > operators that lack operability and maturity, that have not been designed > to be production ready and those issues make it just very hard for users to > find what is useful. > > New features are added from time to time. You can look at past release > notes and you can also get some forward looking idea by following > discussions and pull requests. One of the things I would hope to see added > is the Python support, Kudu connectors and I would also hope to see changes > to the high level Java API, SQL (windowing) and support for watermarks and > batch demarcation in the existing operators. However, discussion of these > isn't relevant to this vote thread. > > > On Fri, Aug 25, 2017 at 6:12 PM, Ashwin Chandra Putta < > ashwinchand...@gmail.com> wrote: > > > 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. > > > > > > > > > > -- ~Milind bee at gee mail dot com
