Another thought If there is going to be a breaking change to public API like remove deprecated method or change signature for a public API - create a copy of this class, possibly keeping the same class name but change the package. Let's say we change the package name from org.ignite.cache to org.ignite.cache.ver2 or similar - move this class as-is to another module named ignite-deprecated or ignite-compatibility-1.x or similar - developers can *strongly try* to keep easy upgrade by extending ver2.class. The class in deprecated/compatibility will probably only have the public API to avoid compilation error and leverage most of the processing from ver2 class
We as developers probably maintain the deprecated/compatibility branch till 2.0 is GA or a bit longer. And going forward, we can accept PR from others but developers cannot guarantee we will keep the compatibility latest. This is a thought - and kinda practical- we have used it within our application for similar breaking changes. Sent from my iPhone > On Dec 7, 2016, at 15:04, Denis Magda <dma...@apache.org> wrote: > > I would remove as much as possible and prepare a migration guide as Sergey K. > suggests below. > > In any case, we will stick to the flexible approach. As the next step I would > split all the existed APIs in 2 groups. The first group will be for the APIs > that will be deleted and we will provide instructions in the migration guide > on how to migrate from them. The second group will be for those that will be > left. > > Actually, there is an already existed ticket for this > https://issues.apache.org/jira/browse/IGNITE-3469 > <https://issues.apache.org/jira/browse/IGNITE-3469> > > — > Denis > >> On 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 >
