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 Sun, 27 Aug 2017 20:41:35 GMT
1.x may not be accurate, but 4.x (as well as 3.x, 2.x or 0.x) may not be 
accurate either. I don't see why 4.x is more accurate than 1.x. In any 
case this is personal preference and there is no *technical* 
justification not to go with 1.x once the artifactId is also changed.

-1 in a discussion thread is different from -1 in the voting thread. In 
a discussion thread it means "I strongly prefer/recommend that the 
community does not go that way". In the voting thread it means "I 
request that the changes are not implemented" (veto). For the veto to be 
valid, there must be *technical* reason not to move forward. In this 
particular case I would consider "maven does not support artifactId 
change" as a valid technical reason for -1. A fact that somebody refers 
to a project as Malhar instead of Apache Apex is not a valid technical 
justification. Up to this point no valid technical justification was 
provided to stop artifactId and version change. I don't take "cost" as a 
valid technical justification either. There was a large cost to enforce 
checkstyle, but benefits from implementing checkstyle were definitely 
worth the cost.

Thank you,

Vlad

On 8/25/17 13:18, Pramod Immaneni wrote:
> Like I said, 1.x is not accurate, the project has already gone through 1.x,
> 2.x and it is at the version it is now. Resetting to 1.x or 1.0-SNAPSHOT is
> arbitrary. When the project was transitioned from non-apache open source to
> apache, a few years back, a case could have been made to reset the version
> as we were respawning life as a new project but not now. Even if we did
> reset the version at that point we cannot say what version we would be at
> now or say for sure we would be 1.0-SNAPSHOT now.
>
> When it comes to changing the name of the malhar project, there is a
> cost, malhar is a known entity with users and apart from the project
> dependency from code perspective, there is literature out there and not
> just on the apex website. This would be literature that our users have
> created describing malhar in the context of their applications or to
> promote apex within their organization, reviews from external entities and
> sites on apex project and other such references. Also, from the code
> perspective even though the specific code changes may look trivial that
> could end up being a development cycle for the users. With the version
> taken out of the equation because of the reasons described above, the cost
> is not justifiable.
>
> I don't know if I can explain the reasons above any other way. Either, you
> don't see my reasons as valid or we have a communication disconnect with
> your insistence that -1 is not valid. I clearly don't see a consensus here,
> there are others who are not in favor of changing the name and resetting
> the version as evidenced by the votes in the voting thread and we should
> end this discussion thread.
>
> Thanks
>
> On Fri, Aug 25, 2017 at 10:18 AM, Vlad Rozov <v.rozov64@gmail.com> wrote:
>
>> I understand the preference and also explained why version and name change
>> is preferable in my view and what is broken with the current name and
>> version. The preference can and should be reflected in the vote, but at the
>> end it's the community decision. I don't see why -1 would be a valid vote
>> at that point.
>>
>> Thank you,
>>
>> Vlad
>>
>>
>> On 8/25/17 09:57, Pramod Immaneni wrote:
>>
>>> No, concerns for the changing the project name and version remain the
>>> same.
>>> I think the current version numbering train and name are fine and prefer
>>> we
>>> move forward and not backward by resetting things back to 1.x, which I
>>> believe is not accurate for the project. The name change is unnecessary,
>>> the name isn't broken that it needs to be fixed, it does not buy us much
>>> and causes unnecessary disruption for people who are already used to
>>> and malhar is already known out there. It is equivalent to asking for
>>> apex-core to be changed to apex-engine, engine is probably a better name
>>> but is it worth making the change, probably not, if it is not broke why
>>> fix
>>> it.
>>>
>>> Thanks
>>>
>>> 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
>>>>
>>>>


Thank you,

Vlad

Mime
View raw message