Major release 2.0 and compilation

[Vladimir Ozerov]

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.

[yzhdanov]

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 <[hidden email]>:

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

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 <[hidden email]> 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 <[hidden email]>:
>
> > 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

[dsetrakyan]

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 <[hidden email]> 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 <[hidden email]>
> 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 <[hidden email]>:
> >
> > > 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
>

[dmagda]

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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>:
>>
>>> 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

[Rohit Mohta]

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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>:
>>>
>>>> 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
>

[Roman Shtykh]

Rohit,

I don't think this is a very clean approach to maintain multiple copies.

+1 for removing deprecated stuff in 2.0 with some exclusions and thoroughly documenting and sharing the changes as it was proposed above.

-Roman




On Thursday, December 8, 2016 10:47 AM, Rohit Mohta <[hidden email]> wrote:
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>:
>>>
>>>> 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
>

[Alexey Kuznetsov]

+1 for removing deprecated stuff in 2.0 and provide "Migration guide".

In any case we are going to break compatibility.

--
Alexey Kuznetsov

[Rohit Mohta]

Agreed. Was just thinking from end user perspective - as Ignite is gaining traction and teams are building application, a news like breaking compatibility can cause some concerns. Something similar to AngularJS when they declared similar news.

 Regardless of the approach we take, excited about 2.0. 👍

Sent from my iPhone

> On Dec 7, 2016, at 19:56, Alexey Kuznetsov <[hidden email]> wrote:
>
> +1 for removing deprecated stuff in 2.0 and provide "Migration guide".
>
> In any case we are going to break compatibility.
>
> --
> Alexey Kuznetsov

[Taras Ledkov]

I've updated the issue:
https://issues.apache.org/jira/browse/IGNITE-3469 with two lists of
deprecated API: public and private.

Please take a look. I would create sub tasks for each to make review
simpler then one huge patch that contains the whole refactoring.

The list of the deprecated public class / methods / properties:

- two methods IgniteCluster.mapKeyToNode - the removing is simple
because its are used rare;
- IgniteCache.randomEntry - the removing is simple because it is used rare;
- The system flags:
     - IGNITE_BINARY_SORT_OBJECT_FIELDS;
     - IGNITE_BINARY_DONT_WRAP_TREE_STRUCTURES;
     - IGNITE_MIN_BUFFERED_COMMUNICATION_MSG_CNT - not used in the
projects now.
- CacheTypeMetadata;
- Classes related with AffinityNodeHashResolver;
- Backup filters for affinity functions;
- RandomEvictionPolicy;
- ContinuousQuery.setRemoteFilter;
- CacheStore.sessionEnd;
- CacheAbstractJdbcStore.translateFields;
- CacheJdbcPojoStoreFactory.setDataSource;
- CacheConfiguration properties: transactionManagerLookupClassName and
{rebalanceThreadPoolSize}};
- ConnectorConfiguration.sslContextFactory property;
- FileSystemConfiguration properties:
     - fragmentizerLocalWritesRatio;
     - trashPurgeTimeout;
     - dualModePutExecutorService;
     - dualModePutExecutorServiceShutdown;
     - dualModeMaxPendingPutsSize;
- IgniteConfiguration properties:
     - nodeId;
     - DFLT_PUBLIC_KEEP_ALIVE_TIME;
     - DFLT_PUBLIC_THREADPOOL_QUEUE_CAP;
     - DFLT_SYSTEM_MAX_THREAD_CNT;
     - DFLT_SYSTEM_KEEP_ALIVE_TIME;
     - DFLT_UTILITY_KEEP_ALIVE_TIME;
     - DFLT_SYSTEM_THREADPOOL_QUEUE_CAP;
- TransactionConfiguration properties:
     - txSerializableEnabled;
     - txManagerLookupClassName;
- Several methods at the IgfsPath class: empty constructor, root() and
isSame methods;
- IgniteSpiContext: methods addMessageListener, removeMessageListener;
- TcpCommunicationSpi properties:
     - connectionBufferSize;
     - connectionBufferFlushFrequency;
     - minimumBufferedMessageCount;
- StreamTupleExtractor class and relations;
- ignite-hadoop: Several constructors of the
IgniteHadoopIgfsSecondaryFileSystem;
- ignite-yarn: ApplicationMaster.getContainers().

The list of the deprecated private class / methods / properties:

- Classes are retated to the GridSslContextFactory;
- JdbcConnection related classes;
- GridCacheUtils.cheatCache;
- GridCacheCommittedTxInfo;
- GridDistributedTxFinishRequest: syncCommit, syncRollback;
- GridDhtPartitionDemander: demandLock, dmIdx, worker, SupplyMessage,
DemandWorker;
- One of the constructors of the GridDhtPartitionFullMap;
- GridDhtPartitionMap;
- GridDhtPartitionSupplier old listeners & old demand message;
- AffinityTask.affinityKey()
- GridQueryRequest;
- One of the constructors of GridLeanSet;
- Several methods at the IgniteUtils;
- Several methods at the GridFunc;
- GridTupleV;
- PlatformDotNetBinaryTypeConfiguration.isKeepDeserialized();
- ServerImpl.RingMessageWorker.processNodeAddedMessage;
- TcpDiscoverySpi.versionCheckFailed;

On 08.12.2016 1:04, Denis Magda 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>:
>>>
>>>> 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
>

--
Taras Ledkov
Mail-To: [hidden email]

[dsetrakyan]

Thanks, Taras! I think this definitely should be included in the release
notes and somewhere in the documentation.

On Tue, Feb 21, 2017 at 2:50 AM, Taras Ledkov <[hidden email]> wrote:

> I've updated the issue: https://issues.apache.org/jira/browse/IGNITE-3469
> with two lists of deprecated API: public and private.
>
> Please take a look. I would create sub tasks for each to make review
> simpler then one huge patch that contains the whole refactoring.
>
> The list of the deprecated public class / methods / properties:
>
> - two methods IgniteCluster.mapKeyToNode - the removing is simple because
> its are used rare;
> - IgniteCache.randomEntry - the removing is simple because it is used rare;
> - The system flags:
>     - IGNITE_BINARY_SORT_OBJECT_FIELDS;
>     - IGNITE_BINARY_DONT_WRAP_TREE_STRUCTURES;
>     - IGNITE_MIN_BUFFERED_COMMUNICATION_MSG_CNT - not used in the
> projects now.
> - CacheTypeMetadata;
> - Classes related with AffinityNodeHashResolver;
> - Backup filters for affinity functions;
> - RandomEvictionPolicy;
> - ContinuousQuery.setRemoteFilter;
> - CacheStore.sessionEnd;
> - CacheAbstractJdbcStore.translateFields;
> - CacheJdbcPojoStoreFactory.setDataSource;
> - CacheConfiguration properties: transactionManagerLookupClassName and
> {rebalanceThreadPoolSize}};
> - ConnectorConfiguration.sslContextFactory property;
> - FileSystemConfiguration properties:
>     - fragmentizerLocalWritesRatio;
>     - trashPurgeTimeout;
>     - dualModePutExecutorService;
>     - dualModePutExecutorServiceShutdown;
>     - dualModeMaxPendingPutsSize;
> - IgniteConfiguration properties:
>     - nodeId;
>     - DFLT_PUBLIC_KEEP_ALIVE_TIME;
>     - DFLT_PUBLIC_THREADPOOL_QUEUE_CAP;
>     - DFLT_SYSTEM_MAX_THREAD_CNT;
>     - DFLT_SYSTEM_KEEP_ALIVE_TIME;
>     - DFLT_UTILITY_KEEP_ALIVE_TIME;
>     - DFLT_SYSTEM_THREADPOOL_QUEUE_CAP;
> - TransactionConfiguration properties:
>     - txSerializableEnabled;
>     - txManagerLookupClassName;
> - Several methods at the IgfsPath class: empty constructor, root() and
> isSame methods;
> - IgniteSpiContext: methods addMessageListener, removeMessageListener;
> - TcpCommunicationSpi properties:
>     - connectionBufferSize;
>     - connectionBufferFlushFrequency;
>     - minimumBufferedMessageCount;
> - StreamTupleExtractor class and relations;
> - ignite-hadoop: Several constructors of the IgniteHadoopIgfsSecondaryFileS
> ystem;
> - ignite-yarn: ApplicationMaster.getContainers().
>
> The list of the deprecated private class / methods / properties:
>
> - Classes are retated to the GridSslContextFactory;
> - JdbcConnection related classes;
> - GridCacheUtils.cheatCache;
> - GridCacheCommittedTxInfo;
> - GridDistributedTxFinishRequest: syncCommit, syncRollback;
> - GridDhtPartitionDemander: demandLock, dmIdx, worker, SupplyMessage,
> DemandWorker;
> - One of the constructors of the GridDhtPartitionFullMap;
> - GridDhtPartitionMap;
> - GridDhtPartitionSupplier old listeners & old demand message;
> - AffinityTask.affinityKey()
> - GridQueryRequest;
> - One of the constructors of GridLeanSet;
> - Several methods at the IgniteUtils;
> - Several methods at the GridFunc;
> - GridTupleV;
> - PlatformDotNetBinaryTypeConfiguration.isKeepDeserialized();
> - ServerImpl.RingMessageWorker.processNodeAddedMessage;
> - TcpDiscoverySpi.versionCheckFailed;
>
>
> On 08.12.2016 1:04, Denis Magda 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 <[hidden email]> 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 <[hidden email]>
>>> 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 <[hidden email]>:
>>>>
>>>> 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
>>>
>>
>>
> --
> Taras Ledkov
> Mail-To: [hidden email]
>
>