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. >
