apex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Amol Kekre <a...@datatorrent.com>
Subject Re: Backward compatibility issue in 3.6.0 release
Date Mon, 15 May 2017 18:33:19 GMT
I agree with Vlad; I would suggest option 1 too, but not a patch release.
Documentation should suffice.

Thks,
Amol


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

www.datatorrent.com


On Mon, May 15, 2017 at 11:13 AM, Vlad Rozov <v.rozov@datatorrent.com>
wrote:

> 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
>
> Отправлено с iPhone
>
> > On May 15, 2017, at 10:40, Munagala Ramanath
> <amberarrow@yahoo.com.INVALID> wrote:
> >
> > 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 <ajaygit158@gmail.com>
> 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 to release a 3.6.1 patch release as
> > well.
> >
> >
> > Ajay
> >
> > On Mon, May 15, 2017 at 10:36 PM, Sanjay Pujare <sanjay@datatorrent.com>
> > wrote:
> >
> >> 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 <v.rozov@datatorrent.com>
> >> wrote:
> >>
> >>> 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 the Default Input and Output Ports in
> >> the
> >>> next release (3.7.0), declare protected variables as private and
> provide
> >>> protected access method. Another option is to rename protected
> variables
> >> to
> >>> use less common names (for example __count).
> >>> 2. Keep protected variables with the risk that the following common
> >>> operator design pattern will be used accidentally by existing operators
> >> and
> >>> newly designed operators:
> >>>
> >>> public Operator extends BaseOperator {
> >>>   private int count;
> >>>   public DefaultInputPort in = new DefaultInputPort() {
> >>>     @Override
> >>>     public void process(Object tuple)
> >>>     {
> >>>         count++;  // updates DefaultInputPort count, not Operator
> count!
> >>>     }
> >>>   }
> >>> }
> >>>
> >>>
> >>> Thank you,
> >>>
> >>> Vlad
> >>>
> >>
> >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message