apex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Amol Kekre <a...@datatorrent.com>
Subject Re: [DISCUSS] changing project name to apex-library
Date Fri, 25 Aug 2017 16:17:45 GMT
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:amol@datatorrent.com | M: 510-449-2606 | Twitter: @*amolhkekre*

www.datatorrent.com


On Fri, Aug 25, 2017 at 9:01 AM, Vlad Rozov <vrozov@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 <amol@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 <vrozov@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 <vrozov@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 <
>>>>>>> justin@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
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message