apex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vlad Rozov <vro...@apache.org>
Subject Re: [DISCUSS] changing project name to apex-library
Date Thu, 24 Aug 2017 17:18:35 GMT
The gain is consistency and meeting/setting up expectations on the 
project quality/maturity.

Thank you,

Vlad

On 8/24/17 09:42, Amol Kekre wrote:
> In terms of rebasing versions, there is no urgency in mimic-ing some of the
> other projects. Apex has already be been versioned. 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.
>
> Thks,
> Amol
>
>
> E:amol@datatorrent.com | M: 510-449-2606 | Twitter: @*amolhkekre*
>
> www.datatorrent.com
>
>
> 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
View raw message