ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dmitriy Setrakyan <dsetrak...@apache.org>
Subject Re: Major release 2.0 and compilation
Date Wed, 07 Dec 2016 18:18:12 GMT
I would vote for removing the deprecated APIs, unless it may be absolutely
harmful to the community. For example, if we have deprecated configuration
properties, I would definitely remove them and force users to update to the
new configuration.

However, if there is some deprecation in a compute method, or, maybe,
cache.put(...) method, then removing such methods will be plain harmful. I
would keep them till Ignite 3.0 and print out a warning in the log that
this deprecated method will be removed in the next version of Ignite.

D.

On Wed, Dec 7, 2016 at 10:12 AM, Sergey Kozlov <skozlov@gridgain.com> wrote:

> I would remind that Apache Ignite 1.0.0 has been released 20 months ago and
> probably 2.0 will be rolled out close to the second anniversary of initial
> release. It's right time to remove deprecated API and provide for users the
> clear ways for migration 1.x to 2.0.
>
> I think we could create a wiki page for users who can recompile their
> applications, list all deprecated API calls and provide migration's
> tips/tricks from deprecated features to new ones (something like the table
> with columns "Deprecated API call for 1.x", "API call for 2.0/workaround").
>
>
>
> On Wed, Dec 7, 2016 at 11:36 AM, Yakov Zhdanov <yzhdanov@apache.org>
> wrote:
>
> > Agree with Vladimir that we should use flexible approach and should avoid
> > any possible harm here, but cleaning out most of deprecations is the way
> to
> > go, IMO. There are about 90 occurrences of "deprecated" in the project
> and
> > most of them are not very hard to remove. Moreover, we have, for example,
> > setRemoteFilter(CacheEntryEventSerializableFilter<K, V>). Using this
> > method
> > is error prone. We should remove it so none can use it.
> >
> > Cleaning up and renovating are good. This allows us to see what can be
> done
> > better and also encourages users to move forward.
> >
> > --Yakov
> >
> > 2016-12-07 15:22 GMT+07:00 Vladimir Ozerov <vozerov@gridgain.com>:
> >
> > > Igniters,
> > >
> > > Release Apache Ignite 2.0 is already planned and being discussed.
> > Normally
> > > we do not brake compilation between minor releases, and if some method
> on
> > > public API should not be used anymore we mark it as *deprecated*. But
> we
> > do
> > > not have such a rule for major releases. The question is whether we are
> > > going to break compilation and remove deprecated methods from public
> API
> > in
> > > Apache ignite 2.0 or not. There are several extreme approaches to this.
> > >
> > > First, we can declare that we cleanup all deprecations and remove them.
> > > This will result in clean and consistent API and simplify further
> > > development. But it might slowdown adoption of Apache Ignite 2.0
> because
> > > users will be reluctant switching to newer version because they will
> have
> > > to fix compilation, re-deploy their apps, etc..
> > >
> > > Second, we can say that we must avoid breaking compilation at all costs
> > and
> > > retain deprecated methods. This approach might be better for users, for
> > > harder to maintain for Ignite developers. With this approach users will
> > > migrate to 2.0 quicker.
> > >
> > > My opinion is that we must choose flexible approach and decide whether
> to
> > > keep deprecation or not separately for every piece of API, depending on
> > > possible impact on both users and Ignite developers. But normally I
> would
> > > leave deprecation unless there is a strong reason to remove it.
> > >
> > > Thoughts?
> > >
> > > Vladimir.
> > >
> >
>
>
>
> --
> Sergey Kozlov
> GridGain Systems
> www.gridgain.com
>

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