On 8/27/17 16:09, Pramod Immaneni wrote:
On Sun, Aug 27, 2017 at 1:41 PM, Vlad Rozov <vro...@apache.org> wrote:
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.
4.x would be much better justified than 1.x because we are right now on 3.8
dev, thinking about making incompatible changes and combined with the fact
that we haven't been on 3.x only for a short period, logic would dictate
going to the next major version.
It is all subjective. I don't think that the current 3.8 version is
accurate and properly reflects quality and maturity of the library.
-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.
By that logic there is no techical issue with renaming apex-core or
apex-malhar to apex-<anything> because almost anything will technically
work with maven and other tools. That being the only criteria doesn't make
sense and is not the case. One of the mentors noted the same in one of the
threads. There is no agreement that the project name should be changed and
so with justifiable reasons.
If there is a reason to change apex to apex-<anything>, so the majority
of the community decides to make the change, I, as an individual
contributor/committer/PMC member, can't stop it by vetoing the change.
Yes, there is no agreement that the project name should be changed, but
also there is no agreement that it should continue under the same name.
A few members of the community including several PMCs prefer to change
the name and the version.
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.
That is a incorrect analogy, checkstyle was internal. It did not impact
users. What you are asking for, may not impact devs who are developing apex
as much but it impacts users and hence has "cost" that I detailed in my
earlier email and if it wasn't clear from my earlier emails is not good for
the continued adoption of the project. Regarding the technical
justification see my comment above.
We already discussed this. Externally, upgrade to 4.0 that you don't
seem to object is equivalent to artifact change combined with the
version change to 1.0.
For example netty was renamed to netty-all
(https://mvnrepository.com/artifact/io.netty/netty) and netty adoption
(https://mvnrepository.com/artifact/io.netty/netty/usages) is the order
of magnitude more than Malhar adoption
(https://mvnrepository.com/artifact/org.apache.apex/malhar-library/usages).
A single brand that is better for the future adoption is the
justification for the internal cost of the rename.
Thanks
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.rozo...@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 <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
Thank you,
Vlad
