For -1 to be valid there *must* be *technical* justification(s) not to
proceed with the code change. Without such justification -1 is
considered to be void/invalid [1].
I don't see any possible *technical* justification not to proceed with
the package rename as it was done in the past by a large number of
Apache (and not only Apache) projects and nothing bad happened (no
performance degradation, no introduction of security vulnerability) and
projects remained usable by their users. With the current IDEs, it is a
question of 5 minutes to complete necessary modifications.
Both Apache Felix and Apache Groovy (as well as Apache Apex) are split
package projects. There is mix and match of org.apache.* and other
package names (org.osgi, groovy, com.datatorrent). IMO, this is a bad
practice and I don't think that Apex community should use those projects
as a best practice examples. Majority of Apache projects consistently
use org.apache package and IMO that simplifies user and community
experience.
Majority of malhar library classes are excluded from semantic versioning
check and are not subject of backward compatibility/stable API
guarantee. Due to that there never be a good reason to change major
version as backward incompatible changes are introduced silently and
without proper semantic versioning.
Thank you,
Vlad
[1] https://www.apache.org/foundation/voting.html
On 8/23/17 15:17, Sergey Golovko wrote:
-1 for the option 2
I don't think it makes sense to rush to rename the package name. There are
Apache Java projects that use the original package names after migration to
Apache Software Foundation. For instance,
Apache Felix <https://projects.apache.org/project.html?felix> (org.osgi)
Apache Groovy <https://projects.apache.org/project.html?groovy> (groovy)
Personally I don't like the idea to rename package names for any existing
tools and applications. It can just be a big confusion for users without
any real benefits.
-1 for the option 1
I see only one valid reason to change the major version now. It is the full
refactoring of the code without supporting of any backward compatibility.
If we are going to make the package refactoring we need to change the major
version. If we are not going to do it now, it does not make sense to
change the major version. I don't think it makes sense to vote for the two
options separately.
Thanks,
Sergey
On Wed, Aug 23, 2017 at 6:39 AM, Thomas Weise <t...@apache.org> wrote:
So far everyone else has voted +1 on option 1. Your -1 is not a veto
(unlike your previous -1 on a pull request), but your response also states
"I am for option 1" and that you want to have the branch release-3
included. So why don't you include that into your vote for option 1 as a
condition, since that's what is going to happen anyways.
Thomas
On Tue, Aug 22, 2017 at 6:17 PM, Amol Kekre <a...@datatorrent.com> wrote:
On just voting part, I remain -1 on both options
Thks
Amol
On Tue, Aug 22, 2017 at 10:03 AM, Amol Kekre <a...@datatorrent.com> wrote:
I am -1 on option 2. There is no need to do so, as going back on versions
at this stage has consequences to Apex users.
I am for option 1, but I want to propose explicit change to the text.
Based
on verbatim text, I am voting -1 on option 1. I believe in the original
discussion thread there was talk about continuing release-3 that should
be
explicit in the vote.
Thank you,
Vlad
