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 <skoz...@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 <yzhda...@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 <voze...@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 >
