[jira] [Resolved] (APEXCORE-704) Add supporting of programmatic logger appender

[ https://issues.apache.org/jira/browse/APEXCORE-704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vlad Rozov resolved APEXCORE-704. - Resolution: Implemented Fix Version/s: 3.7.0 > Add supporting of programmatic logger

[jira] [Commented] (APEXCORE-704) Add supporting of programmatic logger appender

[ https://issues.apache.org/jira/browse/APEXCORE-704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16011538#comment-16011538 ] Vlad Rozov commented on APEXCORE-704: - [~sgolovko] Please document format required to add new

[jira] [Commented] (APEXCORE-704) Add supporting of programmatic logger appender

[ https://issues.apache.org/jira/browse/APEXCORE-704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16011533#comment-16011533 ] ASF GitHub Bot commented on APEXCORE-704: - Github user asfgit closed the pull request at:

[GitHub] apex-core pull request #515: APEXCORE-704 Add supporting of programmatic log...

Github user asfgit closed the pull request at: https://github.com/apache/apex-core/pull/515 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is

Re: Backward compatibility issue in 3.6.0 release

I am slightly in favor of getters and setters approach as well. Likely hotspot will optimize extra call anyway. Thank you, Vlad Отправлено с iPhone > On May 15, 2017, at 10:51, Bhupesh Chawda wrote: > > I also suggest going for 1. > But I think we should make

Re: Backward compatibility issue in 3.6.0 release

I agree with Vlad; I would suggest option 1 too, but not a patch release. Documentation should suffice. Thks, Amol E:a...@datatorrent.com | M: 510-449-2606 | Twitter: @*amolhkekre* www.datatorrent.com On Mon, May 15, 2017 at 11:13 AM, Vlad Rozov wrote: > I

Re: Backward compatibility issue in 3.6.0 release

I considered proposing 3.6.1 patch release, but rejected it as API changes do not qualify for the patch release. Note that this is a compile time backward compatibility issue, not a run-time. Instead of 3.6.1 I would propose to spell out the issue in 3.6.0 documentation. Thank you, Vlad

Re: Backward compatibility issue in 3.6.0 release

I also suggest going for 1. But I think we should make variables private and provide protected getters and setters. ~ Bhupesh On May 15, 2017 23:18, "Bhupesh Chawda" wrote: Actually Ajay discovered this when upgrading the core dependency test. One of the tests was

Re: Backward compatibility issue in 3.6.0 release

Actually Ajay discovered this when upgrading the core dependency test. One of the tests was failing. ~ Bhupesh On May 15, 2017 23:15, "Pramod Immaneni" wrote: I would suggest going with 1. Bhupesh how did you see this? Did it see it as part of working on an operator in

Re: Backward compatibility issue in 3.6.0 release

I would suggest going with 1. Bhupesh how did you see this? Did it see it as part of working on an operator in Malhar? On Mon, May 15, 2017 at 9:53 AM, Vlad Rozov wrote: > Hi All, > > There is a possible change in operators behavior caused by changes that > were

Re: Backward compatibility issue in 3.6.0 release

I like proposal 1 too; I also agree with Ajay about doing a 2.6.1 patch release. Ram On Monday, May 15, 2017 10:18 AM, AJAY GUPTA wrote: I would vote for 1 and making variables private since it anyways breaks semantic versioning. I think it would it be a good idea

Re: Backward compatibility issue in 3.6.0 release

I would vote for 1 and making variables private since it anyways breaks semantic versioning. I think it would it be a good idea to release a 3.6.1 patch release as well. Ajay On Mon, May 15, 2017 at 10:36 PM, Sanjay Pujare wrote: > I vote for renaming to less common

Re: Backward compatibility issue in 3.6.0 release

I vote for renaming to less common names like __count. The renaming breaks compatibility from 3.6.0 to 3.7.0 but seems to be the best option. On Mon, May 15, 2017 at 9:53 AM, Vlad Rozov wrote: > Hi All, > > There is a possible change in operators behavior caused by

Re: Backward compatibility issue in 3.6.0 release

I would prefer 1. - treat it as bug and add exception to semver check to fix the issue (in both master and release branch). In light of recent discussions, I think it is necessary to up the review due diligence for changes to the API and those classes in core that are covered by backward

Backward compatibility issue in 3.6.0 release

Hi All, There is a possible change in operators behavior caused by changes that were introduced in the release 3.6.0 into DefaultInputPort and DefaultOutputPort. Please see https://issues.apache.org/jira/browse/APEXCORE-722. We need to agree how to proceed. 1. Break semantic versioning for

[jira] [Updated] (APEXCORE-722) Protected data members in DefaultInputPort and DefaultOutputPort may interfere with user code

[ https://issues.apache.org/jira/browse/APEXCORE-722?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vlad Rozov updated APEXCORE-722: Affects Version/s: 3.6.0 > Protected data members in DefaultInputPort and DefaultOutputPort may

[jira] [Resolved] (APEXMALHAR-2447) No indication from AbstractFileInputOperator when directory is empty

[ https://issues.apache.org/jira/browse/APEXMALHAR-2447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Priyanka Gugale resolved APEXMALHAR-2447. - Resolution: Fixed Fix Version/s: 3.8.0 > No indication from

[jira] [Commented] (APEXMALHAR-2447) No indication from AbstractFileInputOperator when directory is empty

[ https://issues.apache.org/jira/browse/APEXMALHAR-2447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16010054#comment-16010054 ] ASF GitHub Bot commented on APEXMALHAR-2447: Github user asfgit closed the pull request

[GitHub] apex-malhar pull request #619: APEXMALHAR-2447 Notification from AbstractFil...

Github user asfgit closed the pull request at: https://github.com/apache/apex-malhar/pull/619 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature