I think the backward in-compatibility is there in both options. I think we should give sufficient time frame for community members/ users for major changes. So, I'm -1 on both options.
On Fri, Sep 1, 2017 at 5:43 PM, Sandeep Deshmukh <sandeep.deshm...@gmail.com > wrote: > -1 from my side for "1. Version 4.0 as major version change from 3.x" > > > Was out of station for festival season in India so delay in voting and > replying. > > Reason: > I don't see a compelling reason for a major change at this moment. As a > user of Apex, I have developed a system using Apex but now I have to worry > about a potential disrupting change. I have to worry about porting to a new > version or stick to the older version and missing on new features. > > I found features like Control Tuples very useful. They are recently added > and I am sure the newer features added would also be cool. I worry is, in > the startup-mode that I am working on, do I have the bandwidth to move to a > newer version or have to explore other options leaving out Apex. > > Regards > Sandeep > > > > > On Fri, Sep 1, 2017 at 5:32 PM, Priyanka Gugale <pri...@apache.org> wrote: > > > Apologies for being late in discussions. I wanted to understand one > thing. > > As Thomas mentioned some of our operators are not matured enought or > lacks > > operability. Do we know if such operators need any backword incompatible > > changes? e.g. modification to api etc? Do we have plan to promote > operators > > from Evolving to Stable during major version change? I think we should > > think it through. We should list down all possible backword incompatible > > changes, and then cut the release. Let's give sometime to developers to > > come up with such issues in a given time window. A sudden change in major > > version doesn't give us enough time to identify and address all such > issues > > and we may warrent one more major version change shortly. > > > > I will propose let's keep this open for sometime and we focus on > > identifying changes which should go in next major version and then go for > > it. > > > > -1 for immediate release or even making release branch now. > > > > -Priyanka > > > > On Fri, Sep 1, 2017 at 11:41 AM, Milind Barve <mili...@gmail.com> wrote: > > > > > 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 > > > > > > -- *Chaitanya* Software Engineer E: chaita...@datatorrent.com | Twitter: @chaithu1403 www.datatorrent.com | apex.apache.org
