> > > > > >
> > > > > > > wrote:
> > > > > > >
> > > > > > > > I value strict compatibility rules very highly, and would be
> > > happy
> > > > if
> > > > > > we
>
> in a minor release.
> > > > > > > Unfortunately, Ignite is far from that place for now. We don’t
> > have
> > > > any
> > > > > > > distinction between API and internal classes, don’t have
> > > > > > > p
don’t have
> > > > > > plugin-only APIs, etc. All classes are public, everything is
> > > accessible
> > > > > to
> > > > > > user code. We even refer to internal classes in public Javadoc
> > > > > > (e.g. I recall
d there).
> > > > > Considering this, moving CommandHandler from ignite-core to
> > > > > ignite-control-utility
> > > > > doesn't look that bad. It doesn’t differ to much from any other
> > change
> > > > > that
ing this, moving CommandHandler from ignite-core to
> > > > ignite-control-utility
> > > > doesn't look that bad. It doesn’t differ to much from any other
> change
> > > > that removes or renames a class.
> > > > There could be required changes with a
doesn’t differ to much from any other change
> > > that removes or renames a class.
> > > There could be required changes with a higher compatibility impact but
> I
> > > don’t see them after a superficial glance.
> > >
> > > Stan
> > >
> >
required changes with a higher compatibility impact but I
> > don’t see them after a superficial glance.
> >
> > Stan
> >
> > From: Sergey Antonov
> > Sent: 23 января 2019 г. 19:15
> > To: dev@ignite.apache.org
> > Subject: Re: [DISCUSSION] Control.sh glo
; From: Sergey Antonov
> Sent: 23 января 2019 г. 19:15
> To: dev@ignite.apache.org
> Subject: Re: [DISCUSSION] Control.sh global rework in apache ignite 3.0
>
> Stan, thank you for response!
>
> I my view we shouldn't make incompatible changes and switch extendable
> classes (i.e.
Subject: Re: [DISCUSSION] Control.sh global rework in apache ignite 3.0
Stan, thank you for response!
I my view we shouldn't make incompatible changes and switch extendable
classes (i.e. VisorDataTransferObject -> IgniteDataTransferObject) between
minor releases. Therefore we couldn't rework util
Stan, thank you for response!
I my view we shouldn't make incompatible changes and switch extendable
classes (i.e. VisorDataTransferObject -> IgniteDataTransferObject) between
minor releases. Therefore we couldn't rework utility in 2.8 release.
ср, 23 янв. 2019 г. в 18:48, Stanislav Lukyanov :
Hi,
Sounds good. I agree with all points so far.
I don’t really see why to wait for 3.0 though.
As long as the old commands work I think it’s fine to do all of that in a minor
release.
Even moving the code to a separate module is fine as all the classes are
internal and unlikely to be used in
11 matches
Mail list logo
