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:a...@datatorrent.com | M: 510-449-2606 | Twitter: @*amolhkekre*

www.datatorrent.com


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

Reply via email to