Vlad, Concerns have not been addressed. There is a disconnect on the need to do this now, and then on how to do so.
Thks, Amol E:a...@datatorrent.com | M: 510-449-2606 | Twitter: @*amolhkekre* www.datatorrent.com On Fri, Aug 25, 2017 at 9:01 AM, Vlad Rozov <vro...@apache.org> wrote: > How do we move from here? If all the concerns regarding version and > artifactId change are addressed we should move forward with the vote, if > not, it will be good to raise them here rather than in the voting thread. > > Thank you, > > Vlad > > > On 8/24/17 10:26, Thomas Weise wrote: > >> On Thu, Aug 24, 2017 at 9:42 AM, Amol Kekre <a...@datatorrent.com> wrote: >> >> In terms of rebasing versions, there is no urgency in mimic-ing some of >>> the >>> other projects. Apex has already be been versioned. >>> >> >> There is an expectation users have for a version number, which is >> different >> for 3.x or 1.x or 0.x. Apex library maturity is nowhere near 3.x. That was >> already discussed. >> >> What functional gain do >> >>> we have by changing versions, names? Functionality wise Apex users do not >>> gain anything. With regards to bumping to 4.X, we should wait for a >>> proposal/plan for a new functional api. >>> >>> Addition of such API does not require major version change. New API have >> been added and no major version change was done. Major version change is >> for backward incompatible changes. >> >> Examples: >> - rename packages >> - remove deprecated code >> - relocate operators that were not designed for production use >> - change to functionality of operators >> >> There is an illusion of backward compatibility (which does not exist >> today). That cannot be used as justification to not make changes. >> >> >> On Wed, Aug 23, 2017 at 10:26 AM, Vlad Rozov <vro...@apache.org> wrote: >>> >>> Please see my comments in-line. >>>> >>>> Thank you, >>>> >>>> Vlad >>>> >>>> On 8/23/17 09:11, Pramod Immaneni wrote: >>>> >>>> That is not accurate, I have mentioned and probably others as well that >>>>> changing the name of the project would be disruptive to users. Users >>>>> are >>>>> used to using the malhar project and its artifacts a certain way and >>>>> >>>> this >>> >>>> would cause them immediate confusion followed by consternation and then >>>>> changes that could extend beyond their application such as >>>>> documentation >>>>> etc. >>>>> >>>>> Changing the name is as disruptive to users as changing minor/patch >>>> version. I don't see a big difference in changing one line in pom.xml >>>> (version) vs changing 2 lines (version and artifact). There is a bigger >>>> change/disruption that does IMO require major version change and >>>> renaming >>>> project to use the single brand (Apache Apex) at the same time is >>>> beneficial both to the project and users. Changing package and major >>>> version will impact documentation in much bigger way compared to >>>> changing >>>> artifactId. >>>> >>>> Second the project has been around for quite some time and has reached a >>>>> version 3.x, the second part of the proposed change is to reset it back >>>>> >>>> to >>> >>>> 1.0-SNAPSHOT. I don't think that is accurate for the project and the >>>>> maturity it would portray to the users. Not to get subjective but there >>>>> are >>>>> operators in malhar that are best of the breed when it comes to >>>>> >>>> streaming >>> >>>> functionality they achieve. >>>>> >>>>> There are many Apache projects that were around much longer than malhar >>>> and have not yet reached 3.x version even though they are also used in >>>> production and are considered more stable. Number of evolving packages >>>> >>> and >>> >>>> interfaces in malhar do not qualify it for 3.x or 4.x. IMO, version must >>>> >>> be >>> >>>> driven by the engineering/community, not by the marketing. >>>> >>>> Third think about all the changes it would need, code, project >>>>> infrastructure such as github repo and jira project, documentation, >>>>> website >>>>> etc and the time all the developers have to spend to adapt to this. >>>>> Wouldn't we want to spend this time doing something more productive. >>>>> >>>>> I don't think it is as drastic as it looks to be. It was done in a past >>>> and is supported by all tools involved. >>>> >>>> I would think changing a project name and resetting the version is a big >>>>> deal and should be done if there something big to gain for the project >>>>> >>>> by >>> >>>> doing this. What is the big gain we achieve to justify all this >>>>> consternation? If we want to increase adoption, one of the things we >>>>> >>>> need >>> >>>> to do is to provide users with a platform that behaves in an expected >>>>> >>>> and >>> >>>> stable manner. >>>>> >>>>> It will be good to provide details why is it "a big deal". Why changing >>>> groupId was not a big deal and changing artifactId is a big deal? >>>> >>>> I completely agree with the increasing adoption, but it comes from the >>>> quality, not from the quantity and whether version is 1.x, 3.x or 4.x >>>> >>> does >>> >>>> not change the quality of the library. >>>> >>>> Thanks >>>>> >>>>> >>>>> On Wed, Aug 23, 2017 at 8:09 AM Vlad Rozov <vro...@apache.org> wrote: >>>>> >>>>> All -1 are technically void at this point as justification given are >>>>> why >>>>> >>>>>> project may continue without modifications and not why the >>>>>> modification >>>>>> must not be done. Whether we proceed with the vote or with the >>>>>> discussion, arguments should be what are pros and cons of a code >>>>>> >>>>> change, >>> >>>> not that the project may continue without them. The same should apply >>>>>> not only to the current set of changes, but to all future discussions. >>>>>> >>>>>> Thank you, >>>>>> >>>>>> Vlad >>>>>> >>>>>> On 8/23/17 06:54, Thomas Weise wrote: >>>>>> >>>>>> The discussion already took place [1]. There are two options under >>>>>>> >>>>>> vote >>> >>>> out >>>>>> >>>>>> of that discussion and for the first option there is a single -1. Use >>>>>>> >>>>>> of >>> >>>> -1 >>>>>> >>>>>> during voting (and veto on PR) when not showing up during the >>>>>>> >>>>>> preceding >>> >>>> discussion is problematic. >>>>>>> >>>>>>> Thomas >>>>>>> >>>>>>> [1] https://lists.apache.org/thread.html/ >>>>>>> >>>>>> bd1db8a2d01e23b0c0ab98a785f6ee >>> >>>> 9492a1ac9e52d422568a46e5f3@%3Cdev.apex.apache.org%3E >>>>>>> >>>>>>> On Wed, Aug 23, 2017 at 1:58 AM, Justin Mclean < >>>>>>> jus...@classsoftware.com >>>>>>> >>>>>>> wrote: >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>>> Votes are only valid on code modifications with a reason. [1] >>>>>>>> >>>>>>>> However it looks to me that there’s not consensus and which way >>>>>>>> >>>>>>> forward >>> >>>> is >>>>>>> best I would suggest cancelling the vote and having a discussion of >>>>>>> >>>>>> the >>> >>>> benefit or not of making the change. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Justin >>>>>>>> >>>>>>>> 1. https://www.apache.org/foundation/voting.html >>>>>>>> >>>>>>>> Thank you, >>>>>> >>>>>> Vlad >>>>>> >>>>>> >>>>>> Thank you, >>>> >>>> Vlad >>>> >>>> > > Thank you, > > Vlad >
