Re: [VOTE] Major version change for Apex Library (Malhar)

2017-08-22 Thread Amol Kekre 
On just voting part, I remain -1 on both options

Thks
Amol


E:a...@datatorrent.com | M: 510-449-2606 | Twitter: @*amolhkekre*

www.datatorrent.com


On Tue, Aug 22, 2017 at 4:35 PM, Pramod Immaneni 
wrote:

> I think we should take this discussion to a separate thread as it is a vote
> thread. I don't see a need for this change now as there isn't enough
> justification (such as things are falling apart without this) for the
> disruption it will cause. My earlier point is that there was a
> justification when the project started to change the groupid and it is not
> the same now.
>
> Thanks
>
> On Tue, Aug 22, 2017 at 2:45 PM, Vlad Rozov  wrote:
>
> > Do you mean that prior to groupId change nobody was using that groupId or
> > that nobody was using the library itself :)? If nobody was using the
> > library, the version 3.x at the beginning of the project is questionable.
> >
> > My question is why -1 (veto) as long as things won't fall apart either
> way.
> >
> > Thank you,
> >
> > Vlad
> >
> >
> > On 8/22/17 14:09, Pramod Immaneni wrote:
> >
> >> The groupId change was done at the beginning of the project about two
> >> years
> >> ago before there was an apex release for anyone to use.
> >>
> >> On Tue, Aug 22, 2017 at 1:39 PM, Vlad Rozov  wrote:
> >>
> >> I would argue that things won't fall apart in both cases whether
> >>> artifactId and version are changed or not, so I don't see why it is -1
> >>> for
> >>> the option 2. When groupId was changed from com.datatorrent to
> >>> org.apache.apex, things have not fall apart :).
> >>>
> >>> Thank you,
> >>>
> >>> Vlad
> >>>
> >>>
> >>> On 8/22/17 08:31, Pramod Immaneni wrote:
> >>>
> >>> +1 for option 1
>  -1 for option 2 as I see no impending need to do this now, as in if we
>  don't do this, things will fall apart. It will be a source of more
>  disruption and confusion. Malhar has been around for quite some time,
>  evolving and growing during this period and going to version 4.0 would
>  be
>  a
>  natural progression. Since this is a major version change, there is
> more
>  of
>  a license to relegate things that are deemed unsuitable for production
>  use
>  to contrib (an area designated for that purpose), remove deprecated
>  items,
>  move things around and possibly even make backwards incompatible
>  functionality changes so I don't see a need to change the artifact id
>  and
>  identity of the project.
> 
>  Thanks
> 
>  On Tue, Aug 22, 2017 at 8:16 AM, Munagala Ramanath <
>  amberar...@yahoo.com.invalid> wrote:
> 
>  +1 for option 2 (primary)
> 
> > +1 for option 1 (secondary)
> > Ram
> >
> >
> > On Tuesday, August 22, 2017, 6:58:46 AM PDT, Vlad Rozov <
> > vro...@apache.org>
> > wrote:
> >
> > +1 for option 2 (primary)
> > +1 for option 1 (secondary)
> >
> > Thank you,
> >
> > Vlad
> >
> > On 8/21/17 23:37, Ananth G wrote:
> >
> > +1 for option 2 and second vote for option 1
> >>
> >> Have we finalized the library name ? Going from Apex-malhar 3.7 to
> >>
> >> Apex-malhar-1.0 would be counter intuitive. Also it would be great
> if
> > we
> > have an agreed process to mark an operator from @evolving to stable
> > version
> > given we are trying to address this as well as part of the proposal
> >
> > Regards
> >> Ananth
> >>
> >> On 22 Aug 2017, at 11:40 am, Thomas Weise  wrote:
> >>
> >>> +1 for option 2 (second vote +1 for option 1)
> >>>
> >>>
> >>> On Mon, Aug 21, 2017 at 6:39 PM, Thomas Weise 
> >>> wrote:
> >>>
>  This is to formalize the major version change for Malhar discussed
>  in
> 
>  [1].
> >>>
> >> There are two options for major version change. Major version change
> >>
> >>> will
> >>>
> >> rename legacy packages to org.apache.apex sub packages while
> retaining
> >>
> >>> file
> >>>
> >> history in git. Other cleanup such as removing deprecated code is
> also
> >>
> >>> expected.
> 
>  1. Version 4.0 as major version change from 3.x
> 
>  2. Version 1.0 with simultaneous change of Maven artifact IDs
> 
>  Please refer to the discussion thread [1] for reasoning behind
> both
>  of
> 
>  the
> >>>
> >> options.
> >>
> >>> Please vote on both options. Primary vote for your preferred
> option,
>  secondary for the other. Secondary vote can be used when counting
> 
>  primary
> >>>
> >> vote alone isn't conclusive.
> >>
> >>> Vote will be open for at least 72 hours.
> 
>  Thanks,
>  Thomas
> 
>  [1] https://lists.apache.org/thread.html/
> 
>

Re: [VOTE] Major version change for Apex Library (Malhar)

2017-08-22 Thread Pramod Immaneni 
I think we should take this discussion to a separate thread as it is a vote
thread. I don't see a need for this change now as there isn't enough
justification (such as things are falling apart without this) for the
disruption it will cause. My earlier point is that there was a
justification when the project started to change the groupid and it is not
the same now.

Thanks

On Tue, Aug 22, 2017 at 2:45 PM, Vlad Rozov  wrote:

> Do you mean that prior to groupId change nobody was using that groupId or
> that nobody was using the library itself :)? If nobody was using the
> library, the version 3.x at the beginning of the project is questionable.
>
> My question is why -1 (veto) as long as things won't fall apart either way.
>
> Thank you,
>
> Vlad
>
>
> On 8/22/17 14:09, Pramod Immaneni wrote:
>
>> The groupId change was done at the beginning of the project about two
>> years
>> ago before there was an apex release for anyone to use.
>>
>> On Tue, Aug 22, 2017 at 1:39 PM, Vlad Rozov  wrote:
>>
>> I would argue that things won't fall apart in both cases whether
>>> artifactId and version are changed or not, so I don't see why it is -1
>>> for
>>> the option 2. When groupId was changed from com.datatorrent to
>>> org.apache.apex, things have not fall apart :).
>>>
>>> Thank you,
>>>
>>> Vlad
>>>
>>>
>>> On 8/22/17 08:31, Pramod Immaneni wrote:
>>>
>>> +1 for option 1
 -1 for option 2 as I see no impending need to do this now, as in if we
 don't do this, things will fall apart. It will be a source of more
 disruption and confusion. Malhar has been around for quite some time,
 evolving and growing during this period and going to version 4.0 would
 be
 a
 natural progression. Since this is a major version change, there is more
 of
 a license to relegate things that are deemed unsuitable for production
 use
 to contrib (an area designated for that purpose), remove deprecated
 items,
 move things around and possibly even make backwards incompatible
 functionality changes so I don't see a need to change the artifact id
 and
 identity of the project.

 Thanks

 On Tue, Aug 22, 2017 at 8:16 AM, Munagala Ramanath <
 amberar...@yahoo.com.invalid> wrote:

 +1 for option 2 (primary)

> +1 for option 1 (secondary)
> Ram
>
>
> On Tuesday, August 22, 2017, 6:58:46 AM PDT, Vlad Rozov <
> vro...@apache.org>
> wrote:
>
> +1 for option 2 (primary)
> +1 for option 1 (secondary)
>
> Thank you,
>
> Vlad
>
> On 8/21/17 23:37, Ananth G wrote:
>
> +1 for option 2 and second vote for option 1
>>
>> Have we finalized the library name ? Going from Apex-malhar 3.7 to
>>
>> Apex-malhar-1.0 would be counter intuitive. Also it would be great if
> we
> have an agreed process to mark an operator from @evolving to stable
> version
> given we are trying to address this as well as part of the proposal
>
> Regards
>> Ananth
>>
>> On 22 Aug 2017, at 11:40 am, Thomas Weise  wrote:
>>
>>> +1 for option 2 (second vote +1 for option 1)
>>>
>>>
>>> On Mon, Aug 21, 2017 at 6:39 PM, Thomas Weise 
>>> wrote:
>>>
 This is to formalize the major version change for Malhar discussed
 in

 [1].
>>>
>> There are two options for major version change. Major version change
>>
>>> will
>>>
>> rename legacy packages to org.apache.apex sub packages while retaining
>>
>>> file
>>>
>> history in git. Other cleanup such as removing deprecated code is also
>>
>>> expected.

 1. Version 4.0 as major version change from 3.x

 2. Version 1.0 with simultaneous change of Maven artifact IDs

 Please refer to the discussion thread [1] for reasoning behind both
 of

 the
>>>
>> options.
>>
>>> Please vote on both options. Primary vote for your preferred option,
 secondary for the other. Secondary vote can be used when counting

 primary
>>>
>> vote alone isn't conclusive.
>>
>>> Vote will be open for at least 72 hours.

 Thanks,
 Thomas

 [1] https://lists.apache.org/thread.html/

 bd1db8a2d01e23b0c0ab98a785f6ee
>>>
>> 9492a1ac9e52d422568a46e5f3@%3Cdev.apex.apache.org%3E
>>
>>>
 Thank you,
>
> Vlad
>
>
> Thank you,
>>>
>>> Vlad
>>>
>>>
>
> Thank you,
>
> Vlad
>

Re: [VOTE] Major version change for Apex Library (Malhar)

2017-08-22 Thread Vlad Rozov 
Do you mean that prior to groupId change nobody was using that groupId 
or that nobody was using the library itself :)? If nobody was using the 
library, the version 3.x at the beginning of the project is questionable.


My question is why -1 (veto) as long as things won't fall apart either way.

Thank you,

Vlad

On 8/22/17 14:09, Pramod Immaneni wrote:

The groupId change was done at the beginning of the project about two years
ago before there was an apex release for anyone to use.

On Tue, Aug 22, 2017 at 1:39 PM, Vlad Rozov  wrote:


I would argue that things won't fall apart in both cases whether
artifactId and version are changed or not, so I don't see why it is -1 for
the option 2. When groupId was changed from com.datatorrent to
org.apache.apex, things have not fall apart :).

Thank you,

Vlad


On 8/22/17 08:31, Pramod Immaneni wrote:


+1 for option 1
-1 for option 2 as I see no impending need to do this now, as in if we
don't do this, things will fall apart. It will be a source of more
disruption and confusion. Malhar has been around for quite some time,
evolving and growing during this period and going to version 4.0 would be
a
natural progression. Since this is a major version change, there is more
of
a license to relegate things that are deemed unsuitable for production use
to contrib (an area designated for that purpose), remove deprecated items,
move things around and possibly even make backwards incompatible
functionality changes so I don't see a need to change the artifact id and
identity of the project.

Thanks

On Tue, Aug 22, 2017 at 8:16 AM, Munagala Ramanath <
amberar...@yahoo.com.invalid> wrote:

+1 for option 2 (primary)

+1 for option 1 (secondary)
Ram


On Tuesday, August 22, 2017, 6:58:46 AM PDT, Vlad Rozov <
vro...@apache.org>
wrote:

+1 for option 2 (primary)
+1 for option 1 (secondary)

Thank you,

Vlad

On 8/21/17 23:37, Ananth G wrote:


+1 for option 2 and second vote for option 1

Have we finalized the library name ? Going from Apex-malhar 3.7 to


Apex-malhar-1.0 would be counter intuitive. Also it would be great if we
have an agreed process to mark an operator from @evolving to stable
version
given we are trying to address this as well as part of the proposal


Regards
Ananth

On 22 Aug 2017, at 11:40 am, Thomas Weise  wrote:

+1 for option 2 (second vote +1 for option 1)


On Mon, Aug 21, 2017 at 6:39 PM, Thomas Weise  wrote:

This is to formalize the major version change for Malhar discussed in


[1].

There are two options for major version change. Major version change

will

rename legacy packages to org.apache.apex sub packages while retaining

file

history in git. Other cleanup such as removing deprecated code is also

expected.

1. Version 4.0 as major version change from 3.x

2. Version 1.0 with simultaneous change of Maven artifact IDs

Please refer to the discussion thread [1] for reasoning behind both of


the

options.

Please vote on both options. Primary vote for your preferred option,
secondary for the other. Secondary vote can be used when counting


primary

vote alone isn't conclusive.

Vote will be open for at least 72 hours.

Thanks,
Thomas

[1] https://lists.apache.org/thread.html/


bd1db8a2d01e23b0c0ab98a785f6ee

9492a1ac9e52d422568a46e5f3@%3Cdev.apex.apache.org%3E



Thank you,

Vlad



Thank you,

Vlad




Thank you,

Vlad

Re: [VOTE] Major version change for Apex Library (Malhar)

2017-08-22 Thread Vlad Rozov 
I would argue that things won't fall apart in both cases whether 
artifactId and version are changed or not, so I don't see why it is -1 
for the option 2. When groupId was changed from com.datatorrent to 
org.apache.apex, things have not fall apart :).


Thank you,

Vlad

On 8/22/17 08:31, Pramod Immaneni wrote:

+1 for option 1
-1 for option 2 as I see no impending need to do this now, as in if we
don't do this, things will fall apart. It will be a source of more
disruption and confusion. Malhar has been around for quite some time,
evolving and growing during this period and going to version 4.0 would be a
natural progression. Since this is a major version change, there is more of
a license to relegate things that are deemed unsuitable for production use
to contrib (an area designated for that purpose), remove deprecated items,
move things around and possibly even make backwards incompatible
functionality changes so I don't see a need to change the artifact id and
identity of the project.

Thanks

On Tue, Aug 22, 2017 at 8:16 AM, Munagala Ramanath <
amberar...@yahoo.com.invalid> wrote:


+1 for option 2 (primary)
+1 for option 1 (secondary)
Ram


On Tuesday, August 22, 2017, 6:58:46 AM PDT, Vlad Rozov 
wrote:

+1 for option 2 (primary)
+1 for option 1 (secondary)

Thank you,

Vlad

On 8/21/17 23:37, Ananth G wrote:

+1 for option 2 and second vote for option 1

Have we finalized the library name ? Going from Apex-malhar 3.7 to

Apex-malhar-1.0 would be counter intuitive. Also it would be great if we
have an agreed process to mark an operator from @evolving to stable version
given we are trying to address this as well as part of the proposal

Regards
Ananth


On 22 Aug 2017, at 11:40 am, Thomas Weise  wrote:

+1 for option 2 (second vote +1 for option 1)



On Mon, Aug 21, 2017 at 6:39 PM, Thomas Weise  wrote:

This is to formalize the major version change for Malhar discussed in

[1].

There are two options for major version change. Major version change

will

rename legacy packages to org.apache.apex sub packages while retaining

file

history in git. Other cleanup such as removing deprecated code is also
expected.

1. Version 4.0 as major version change from 3.x

2. Version 1.0 with simultaneous change of Maven artifact IDs

Please refer to the discussion thread [1] for reasoning behind both of

the

options.

Please vote on both options. Primary vote for your preferred option,
secondary for the other. Secondary vote can be used when counting

primary

vote alone isn't conclusive.

Vote will be open for at least 72 hours.

Thanks,
Thomas

[1] https://lists.apache.org/thread.html/

bd1db8a2d01e23b0c0ab98a785f6ee

9492a1ac9e52d422568a46e5f3@%3Cdev.apex.apache.org%3E



Thank you,

Vlad




Thank you,

Vlad

Re: [VOTE] Major version change for Apex Library (Malhar)

2017-08-22 Thread Thomas Weise 
On Tue, Aug 22, 2017 at 10:03 AM, Amol Kekre  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.
>
>
The branch is assumed to be release-3, there wasn't any objection during
discussion.
Branch names are not important for this vote, branches can be created as
the need arises.



> option 3 (modified option 1)
> 3. Version 4.0 as major version change from 3.x. Community members can
> continue with release-3 (3.9, 3.10, ...). PR merges into release-3 should
> not be blocked if it is not immediately merged into master branch.
>

Any number of minor releases of previous major version can be created
or maintained by those willing to do so, that's standard stuff and can be
discussed in a separate thread.


>
> Over a longer period of time, I expect code to progressively be in version
> 4. Changing package names is usually not a reason for major version
> upgrade. The cause is usually an API change. Currently we are moving to
> version 4, without an ask for API change.
>

Again it is established development process that changes need to go to
master
and can be applied to other branches as deemed necessary by those
interested.
Same situation as for patch releases of past minor release.

IMO we cannot add options after a vote was started.

Use a discussion thread to clarify understanding of what constitutes "API"
and the reality of backward compatibility in Malhar as of today.

Thanks,
Thomas

[jira] [Created] (APEXCORE-778) Refactor DelayOperatorTest

2017-08-22 Thread Vlad Rozov (JIRA) 
Vlad Rozov created APEXCORE-778:
---

 Summary: Refactor DelayOperatorTest
 Key: APEXCORE-778
 URL: https://issues.apache.org/jira/browse/APEXCORE-778
 Project: Apache Apex Core
  Issue Type: Improvement
Reporter: Vlad Rozov
Assignee: Vlad Rozov
Priority: Minor


DelayOperatorTest is flaky as it depends on how quickly checkpoints can be 
persisted to a disk



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: [VOTE] Major version change for Apex Library (Malhar)

2017-08-22 Thread Amol Kekre 
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.

option 3 (modified option 1)
3. Version 4.0 as major version change from 3.x. Community members can
continue with release-3 (3.9, 3.10, ...). PR merges into release-3 should
not be blocked if it is not immediately merged into master branch.

Over a longer period of time, I expect code to progressively be in version
4. Changing package names is usually not a reason for major version
upgrade. The cause is usually an API change. Currently we are moving to
version 4, without an ask for API change.

Thks,
Amol



E:a...@datatorrent.com | M: 510-449-2606 | Twitter: @*amolhkekre*

www.datatorrent.com


On Tue, Aug 22, 2017 at 8:31 AM, Pramod Immaneni 
wrote:

> +1 for option 1
> -1 for option 2 as I see no impending need to do this now, as in if we
> don't do this, things will fall apart. It will be a source of more
> disruption and confusion. Malhar has been around for quite some time,
> evolving and growing during this period and going to version 4.0 would be a
> natural progression. Since this is a major version change, there is more of
> a license to relegate things that are deemed unsuitable for production use
> to contrib (an area designated for that purpose), remove deprecated items,
> move things around and possibly even make backwards incompatible
> functionality changes so I don't see a need to change the artifact id and
> identity of the project.
>
> Thanks
>
> On Tue, Aug 22, 2017 at 8:16 AM, Munagala Ramanath <
> amberar...@yahoo.com.invalid> wrote:
>
> > +1 for option 2 (primary)
> > +1 for option 1 (secondary)
> > Ram
> >
> >
> > On Tuesday, August 22, 2017, 6:58:46 AM PDT, Vlad Rozov <
> vro...@apache.org>
> > wrote:
> >
> > +1 for option 2 (primary)
> > +1 for option 1 (secondary)
> >
> > Thank you,
> >
> > Vlad
> >
> > On 8/21/17 23:37, Ananth G wrote:
> > > +1 for option 2 and second vote for option 1
> > >
> > > Have we finalized the library name ? Going from Apex-malhar 3.7 to
> > Apex-malhar-1.0 would be counter intuitive. Also it would be great if we
> > have an agreed process to mark an operator from @evolving to stable
> version
> > given we are trying to address this as well as part of the proposal
> > >
> > > Regards
> > > Ananth
> > >
> > >> On 22 Aug 2017, at 11:40 am, Thomas Weise  wrote:
> > >>
> > >> +1 for option 2 (second vote +1 for option 1)
> > >>
> > >>
> > >>> On Mon, Aug 21, 2017 at 6:39 PM, Thomas Weise 
> wrote:
> > >>>
> > >>> This is to formalize the major version change for Malhar discussed in
> > [1].
> > >>>
> > >>> There are two options for major version change. Major version change
> > will
> > >>> rename legacy packages to org.apache.apex sub packages while
> retaining
> > file
> > >>> history in git. Other cleanup such as removing deprecated code is
> also
> > >>> expected.
> > >>>
> > >>> 1. Version 4.0 as major version change from 3.x
> > >>>
> > >>> 2. Version 1.0 with simultaneous change of Maven artifact IDs
> > >>>
> > >>> Please refer to the discussion thread [1] for reasoning behind both
> of
> > the
> > >>> options.
> > >>>
> > >>> Please vote on both options. Primary vote for your preferred option,
> > >>> secondary for the other. Secondary vote can be used when counting
> > primary
> > >>> vote alone isn't conclusive.
> > >>>
> > >>> Vote will be open for at least 72 hours.
> > >>>
> > >>> Thanks,
> > >>> Thomas
> > >>>
> > >>> [1] https://lists.apache.org/thread.html/
> > bd1db8a2d01e23b0c0ab98a785f6ee
> > >>> 9492a1ac9e52d422568a46e5f3@%3Cdev.apex.apache.org%3E
> > >>>
> >
> >
> > Thank you,
> >
> > Vlad
> >
>

Re: [VOTE] Major version change for Apex Library (Malhar)

2017-08-22 Thread Pramod Immaneni 
+1 for option 1
-1 for option 2 as I see no impending need to do this now, as in if we
don't do this, things will fall apart. It will be a source of more
disruption and confusion. Malhar has been around for quite some time,
evolving and growing during this period and going to version 4.0 would be a
natural progression. Since this is a major version change, there is more of
a license to relegate things that are deemed unsuitable for production use
to contrib (an area designated for that purpose), remove deprecated items,
move things around and possibly even make backwards incompatible
functionality changes so I don't see a need to change the artifact id and
identity of the project.

Thanks

On Tue, Aug 22, 2017 at 8:16 AM, Munagala Ramanath <
amberar...@yahoo.com.invalid> wrote:

> +1 for option 2 (primary)
> +1 for option 1 (secondary)
> Ram
>
>
> On Tuesday, August 22, 2017, 6:58:46 AM PDT, Vlad Rozov 
> wrote:
>
> +1 for option 2 (primary)
> +1 for option 1 (secondary)
>
> Thank you,
>
> Vlad
>
> On 8/21/17 23:37, Ananth G wrote:
> > +1 for option 2 and second vote for option 1
> >
> > Have we finalized the library name ? Going from Apex-malhar 3.7 to
> Apex-malhar-1.0 would be counter intuitive. Also it would be great if we
> have an agreed process to mark an operator from @evolving to stable version
> given we are trying to address this as well as part of the proposal
> >
> > Regards
> > Ananth
> >
> >> On 22 Aug 2017, at 11:40 am, Thomas Weise  wrote:
> >>
> >> +1 for option 2 (second vote +1 for option 1)
> >>
> >>
> >>> On Mon, Aug 21, 2017 at 6:39 PM, Thomas Weise  wrote:
> >>>
> >>> This is to formalize the major version change for Malhar discussed in
> [1].
> >>>
> >>> There are two options for major version change. Major version change
> will
> >>> rename legacy packages to org.apache.apex sub packages while retaining
> file
> >>> history in git. Other cleanup such as removing deprecated code is also
> >>> expected.
> >>>
> >>> 1. Version 4.0 as major version change from 3.x
> >>>
> >>> 2. Version 1.0 with simultaneous change of Maven artifact IDs
> >>>
> >>> Please refer to the discussion thread [1] for reasoning behind both of
> the
> >>> options.
> >>>
> >>> Please vote on both options. Primary vote for your preferred option,
> >>> secondary for the other. Secondary vote can be used when counting
> primary
> >>> vote alone isn't conclusive.
> >>>
> >>> Vote will be open for at least 72 hours.
> >>>
> >>> Thanks,
> >>> Thomas
> >>>
> >>> [1] https://lists.apache.org/thread.html/
> bd1db8a2d01e23b0c0ab98a785f6ee
> >>> 9492a1ac9e52d422568a46e5f3@%3Cdev.apex.apache.org%3E
> >>>
>
>
> Thank you,
>
> Vlad
>

Re: [VOTE] Major version change for Apex Library (Malhar)

2017-08-22 Thread Munagala Ramanath 
+1 for option 2 (primary)
+1 for option 1 (secondary)
Ram


On Tuesday, August 22, 2017, 6:58:46 AM PDT, Vlad Rozov  
wrote:

+1 for option 2 (primary)
+1 for option 1 (secondary)

Thank you,

Vlad

On 8/21/17 23:37, Ananth G wrote:
> +1 for option 2 and second vote for option 1
>
> Have we finalized the library name ? Going from Apex-malhar 3.7 to 
> Apex-malhar-1.0 would be counter intuitive. Also it would be great if we have 
> an agreed process to mark an operator from @evolving to stable version given 
> we are trying to address this as well as part of the proposal
>
> Regards
> Ananth
>
>> On 22 Aug 2017, at 11:40 am, Thomas Weise  wrote:
>>
>> +1 for option 2 (second vote +1 for option 1)
>>
>>
>>> On Mon, Aug 21, 2017 at 6:39 PM, Thomas Weise  wrote:
>>>
>>> This is to formalize the major version change for Malhar discussed in [1].
>>>
>>> There are two options for major version change. Major version change will
>>> rename legacy packages to org.apache.apex sub packages while retaining file
>>> history in git. Other cleanup such as removing deprecated code is also
>>> expected.
>>>
>>> 1. Version 4.0 as major version change from 3.x
>>>
>>> 2. Version 1.0 with simultaneous change of Maven artifact IDs
>>>
>>> Please refer to the discussion thread [1] for reasoning behind both of the
>>> options.
>>>
>>> Please vote on both options. Primary vote for your preferred option,
>>> secondary for the other. Secondary vote can be used when counting primary
>>> vote alone isn't conclusive.
>>>
>>> Vote will be open for at least 72 hours.
>>>
>>> Thanks,
>>> Thomas
>>>
>>> [1] https://lists.apache.org/thread.html/bd1db8a2d01e23b0c0ab98a785f6ee
>>> 9492a1ac9e52d422568a46e5f3@%3Cdev.apex.apache.org%3E
>>>


Thank you,

Vlad

Re: [VOTE] Major version change for Apex Library (Malhar)

2017-08-22 Thread Vlad Rozov 

+1 for option 2 (primary)
+1 for option 1 (secondary)

Thank you,

Vlad

On 8/21/17 23:37, Ananth G wrote:

+1 for option 2 and second vote for option 1

Have we finalized the library name ? Going from Apex-malhar 3.7 to 
Apex-malhar-1.0 would be counter intuitive. Also it would be great if we have 
an agreed process to mark an operator from @evolving to stable version given we 
are trying to address this as well as part of the proposal

Regards
Ananth


On 22 Aug 2017, at 11:40 am, Thomas Weise  wrote:

+1 for option 2 (second vote +1 for option 1)



On Mon, Aug 21, 2017 at 6:39 PM, Thomas Weise  wrote:

This is to formalize the major version change for Malhar discussed in [1].

There are two options for major version change. Major version change will
rename legacy packages to org.apache.apex sub packages while retaining file
history in git. Other cleanup such as removing deprecated code is also
expected.

1. Version 4.0 as major version change from 3.x

2. Version 1.0 with simultaneous change of Maven artifact IDs

Please refer to the discussion thread [1] for reasoning behind both of the
options.

Please vote on both options. Primary vote for your preferred option,
secondary for the other. Secondary vote can be used when counting primary
vote alone isn't conclusive.

Vote will be open for at least 72 hours.

Thanks,
Thomas

[1] https://lists.apache.org/thread.html/bd1db8a2d01e23b0c0ab98a785f6ee
9492a1ac9e52d422568a46e5f3@%3Cdev.apex.apache.org%3E




Thank you,

Vlad

Re: [VOTE] Major version change for Apex Library (Malhar)

2017-08-22 Thread Ananth G 
+1 for option 2 and second vote for option 1

Have we finalized the library name ? Going from Apex-malhar 3.7 to 
Apex-malhar-1.0 would be counter intuitive. Also it would be great if we have 
an agreed process to mark an operator from @evolving to stable version given we 
are trying to address this as well as part of the proposal

Regards
Ananth

> On 22 Aug 2017, at 11:40 am, Thomas Weise  wrote:
> 
> +1 for option 2 (second vote +1 for option 1)
> 
> 
>> On Mon, Aug 21, 2017 at 6:39 PM, Thomas Weise  wrote:
>> 
>> This is to formalize the major version change for Malhar discussed in [1].
>> 
>> There are two options for major version change. Major version change will
>> rename legacy packages to org.apache.apex sub packages while retaining file
>> history in git. Other cleanup such as removing deprecated code is also
>> expected.
>> 
>> 1. Version 4.0 as major version change from 3.x
>> 
>> 2. Version 1.0 with simultaneous change of Maven artifact IDs
>> 
>> Please refer to the discussion thread [1] for reasoning behind both of the
>> options.
>> 
>> Please vote on both options. Primary vote for your preferred option,
>> secondary for the other. Secondary vote can be used when counting primary
>> vote alone isn't conclusive.
>> 
>> Vote will be open for at least 72 hours.
>> 
>> Thanks,
>> Thomas
>> 
>> [1] https://lists.apache.org/thread.html/bd1db8a2d01e23b0c0ab98a785f6ee
>> 9492a1ac9e52d422568a46e5f3@%3Cdev.apex.apache.org%3E
>>