Thin clients compatibility policy

[Vladimir Ozerov]

Igniters,

I'd like to discuss once again our compatibility policy for thin clients
(.JDBC, ODBC, .NET, Java, etc.). We have no clear rules for now, so let's
try to come to agreement.

Normally database vendors work as follows:
1) There is a set of currently supported database versions
2) There is a set of currently supported JDBC/ODBC drivers
3) Every supported driver can work with every supported database (with
little exclusions to this rule).

That is, they are both backward and forward compatible. I can take latest
Oracle's JDBC and some ancient Oracle version, and it will work, unless
this version reached EOL and is no longer supported. And vice versa - new
database, old driver, all is fine.

This is ideal scheme which I'd like to see in Ignite, but:
1) Our protocol is still relatively young and evolve rapidly
2) AI does not have any maintenance releases, so we cannot define which
version is supported and which is not.
3)

I'd like to propose the following compatibility policy:
1) Maintain forward and backward compatibility between two nearest minor
releases only. E.g. 2.5 can work with 2.4, 2.6 with 2.5, etc.
2) Think of more strict compatibility rules in AI 3.0 because at this point
our protocol will be stable enough.

Thoughts?

Vladimir.

[Nikolay Izhikov-2]

+1 From me.

As I wrote in previous mail-threads,
I think we need to create test framework to be able to test compatibility for all clients we have.

AFAIK, currently, there is no possibility to automatically check compatibility.

В Ср, 06/06/2018 в 11:39 +0300, Vladimir Ozerov пишет:

> Igniters,
>
> I'd like to discuss once again our compatibility policy for thin clients
> (.JDBC, ODBC, .NET, Java, etc.). We have no clear rules for now, so let's
> try to come to agreement.
>
> Normally database vendors work as follows:
> 1) There is a set of currently supported database versions
> 2) There is a set of currently supported JDBC/ODBC drivers
> 3) Every supported driver can work with every supported database (with
> little exclusions to this rule).
>
> That is, they are both backward and forward compatible. I can take latest
> Oracle's JDBC and some ancient Oracle version, and it will work, unless
> this version reached EOL and is no longer supported. And vice versa - new
> database, old driver, all is fine.
>
> This is ideal scheme which I'd like to see in Ignite, but:
> 1) Our protocol is still relatively young and evolve rapidly
> 2) AI does not have any maintenance releases, so we cannot define which
> version is supported and which is not.
> 3)
>
> I'd like to propose the following compatibility policy:
> 1) Maintain forward and backward compatibility between two nearest minor
> releases only. E.g. 2.5 can work with 2.4, 2.6 with 2.5, etc.
> 2) Think of more strict compatibility rules in AI 3.0 because at this point
> our protocol will be stable enough.
>
> Thoughts?
>
> Vladimir.

[Vladimir Ozerov]

Hi Nikolay,

Huge +1 for automated compatibility tests. Luckily, we already did that for
persistence, so probably we can re-use some infrastructure from there.

On Wed, Jun 6, 2018 at 1:20 PM, Nikolay Izhikov <[hidden email]> wrote:

> +1 From me.
>
> As I wrote in previous mail-threads,
> I think we need to create test framework to be able to test compatibility
> for all clients we have.
>
> AFAIK, currently, there is no possibility to automatically check
> compatibility.
>
> В Ср, 06/06/2018 в 11:39 +0300, Vladimir Ozerov пишет:
> > Igniters,
> >
> > I'd like to discuss once again our compatibility policy for thin clients
> > (.JDBC, ODBC, .NET, Java, etc.). We have no clear rules for now, so let's
> > try to come to agreement.
> >
> > Normally database vendors work as follows:
> > 1) There is a set of currently supported database versions
> > 2) There is a set of currently supported JDBC/ODBC drivers
> > 3) Every supported driver can work with every supported database (with
> > little exclusions to this rule).
> >
> > That is, they are both backward and forward compatible. I can take latest
> > Oracle's JDBC and some ancient Oracle version, and it will work, unless
> > this version reached EOL and is no longer supported. And vice versa - new
> > database, old driver, all is fine.
> >
> > This is ideal scheme which I'd like to see in Ignite, but:
> > 1) Our protocol is still relatively young and evolve rapidly
> > 2) AI does not have any maintenance releases, so we cannot define which
> > version is supported and which is not.
> > 3)
> >
> > I'd like to propose the following compatibility policy:
> > 1) Maintain forward and backward compatibility between two nearest minor
> > releases only. E.g. 2.5 can work with 2.4, 2.6 with 2.5, etc.
> > 2) Think of more strict compatibility rules in AI 3.0 because at this
> point
> > our protocol will be stable enough.
> >
> > Thoughts?
> >
> > Vladimir.
>

[Dmitriy Pavlov]

Hi Vyacheslav,

WDYT about applicability of PDS compatibiltiy framework for thin clients?

Sincerely,
Dmitriy Pavlov

ср, 6 июн. 2018 г. в 13:45, Vladimir Ozerov <[hidden email]>:

> Hi Nikolay,
>
> Huge +1 for automated compatibility tests. Luckily, we already did that for
> persistence, so probably we can re-use some infrastructure from there.
>
> On Wed, Jun 6, 2018 at 1:20 PM, Nikolay Izhikov <[hidden email]>
> wrote:
>
> > +1 From me.
> >
> > As I wrote in previous mail-threads,
> > I think we need to create test framework to be able to test compatibility
> > for all clients we have.
> >
> > AFAIK, currently, there is no possibility to automatically check
> > compatibility.
> >
> > В Ср, 06/06/2018 в 11:39 +0300, Vladimir Ozerov пишет:
> > > Igniters,
> > >
> > > I'd like to discuss once again our compatibility policy for thin
> clients
> > > (.JDBC, ODBC, .NET, Java, etc.). We have no clear rules for now, so
> let's
> > > try to come to agreement.
> > >
> > > Normally database vendors work as follows:
> > > 1) There is a set of currently supported database versions
> > > 2) There is a set of currently supported JDBC/ODBC drivers
> > > 3) Every supported driver can work with every supported database (with
> > > little exclusions to this rule).
> > >
> > > That is, they are both backward and forward compatible. I can take
> latest
> > > Oracle's JDBC and some ancient Oracle version, and it will work, unless
> > > this version reached EOL and is no longer supported. And vice versa -
> new
> > > database, old driver, all is fine.
> > >
> > > This is ideal scheme which I'd like to see in Ignite, but:
> > > 1) Our protocol is still relatively young and evolve rapidly
> > > 2) AI does not have any maintenance releases, so we cannot define which
> > > version is supported and which is not.
> > > 3)
> > >
> > > I'd like to propose the following compatibility policy:
> > > 1) Maintain forward and backward compatibility between two nearest
> minor
> > > releases only. E.g. 2.5 can work with 2.4, 2.6 with 2.5, etc.
> > > 2) Think of more strict compatibility rules in AI 3.0 because at this
> > point
> > > our protocol will be stable enough.
> > >
> > > Thoughts?
> > >
> > > Vladimir.
> >
>

[daradurvs]

Hello, Igniters!

I am not familiar with the Ignite's thin client.

I'd suggest defining tests scenarios first, to understand what we need
for testing.

For example, our Compatibility Framework may be used for the following scenario:
1. Start node of a previously released version in separate JVM and fill data;
2. Start thin client of an actual version in local JVM then read and
validate data;

Opposite scenario with new nodes and previously released thin clients
is possible too, but such tests will look difficult. If we need such
scenarios, may be required to extend frameworks API to simplify
coding.


On Wed, Jun 6, 2018 at 2:41 PM, Dmitry Pavlov <[hidden email]> wrote:

> Hi Vyacheslav,
>
> WDYT about applicability of PDS compatibiltiy framework for thin clients?
>
> Sincerely,
> Dmitriy Pavlov
>
> ср, 6 июн. 2018 г. в 13:45, Vladimir Ozerov <[hidden email]>:
>>
>> Hi Nikolay,
>>
>> Huge +1 for automated compatibility tests. Luckily, we already did that
>> for
>> persistence, so probably we can re-use some infrastructure from there.
>>
>> On Wed, Jun 6, 2018 at 1:20 PM, Nikolay Izhikov <[hidden email]>
>> wrote:
>>
>> > +1 From me.
>> >
>> > As I wrote in previous mail-threads,
>> > I think we need to create test framework to be able to test
>> > compatibility
>> > for all clients we have.
>> >
>> > AFAIK, currently, there is no possibility to automatically check
>> > compatibility.
>> >
>> > В Ср, 06/06/2018 в 11:39 +0300, Vladimir Ozerov пишет:
>> > > Igniters,
>> > >
>> > > I'd like to discuss once again our compatibility policy for thin
>> > > clients
>> > > (.JDBC, ODBC, .NET, Java, etc.). We have no clear rules for now, so
>> > > let's
>> > > try to come to agreement.
>> > >
>> > > Normally database vendors work as follows:
>> > > 1) There is a set of currently supported database versions
>> > > 2) There is a set of currently supported JDBC/ODBC drivers
>> > > 3) Every supported driver can work with every supported database (with
>> > > little exclusions to this rule).
>> > >
>> > > That is, they are both backward and forward compatible. I can take
>> > > latest
>> > > Oracle's JDBC and some ancient Oracle version, and it will work,
>> > > unless
>> > > this version reached EOL and is no longer supported. And vice versa -
>> > > new
>> > > database, old driver, all is fine.
>> > >
>> > > This is ideal scheme which I'd like to see in Ignite, but:
>> > > 1) Our protocol is still relatively young and evolve rapidly
>> > > 2) AI does not have any maintenance releases, so we cannot define
>> > > which
>> > > version is supported and which is not.
>> > > 3)
>> > >
>> > > I'd like to propose the following compatibility policy:
>> > > 1) Maintain forward and backward compatibility between two nearest
>> > > minor
>> > > releases only. E.g. 2.5 can work with 2.4, 2.6 with 2.5, etc.
>> > > 2) Think of more strict compatibility rules in AI 3.0 because at this
>> > point
>> > > our protocol will be stable enough.
>> > >
>> > > Thoughts?
>> > >
>> > > Vladimir.
>> >

--
Best Regards, Vyacheslav D.

[Vladimir Ozerov]

Igniters,

Let's discuss how to implement tests in separate thread. At this point it
is more important to agree on compatibility policies.

On Wed, Jun 6, 2018 at 6:02 PM, Vyacheslav Daradur <[hidden email]>
wrote:

> Hello, Igniters!
>
> I am not familiar with the Ignite's thin client.
>
> I'd suggest defining tests scenarios first, to understand what we need
> for testing.
>
> For example, our Compatibility Framework may be used for the following
> scenario:
> 1. Start node of a previously released version in separate JVM and fill
> data;
> 2. Start thin client of an actual version in local JVM then read and
> validate data;
>
> Opposite scenario with new nodes and previously released thin clients
> is possible too, but such tests will look difficult. If we need such
> scenarios, may be required to extend frameworks API to simplify
> coding.
>
>
> On Wed, Jun 6, 2018 at 2:41 PM, Dmitry Pavlov <[hidden email]>
> wrote:
> > Hi Vyacheslav,
> >
> > WDYT about applicability of PDS compatibiltiy framework for thin clients?
> >
> > Sincerely,
> > Dmitriy Pavlov
> >
> > ср, 6 июн. 2018 г. в 13:45, Vladimir Ozerov <[hidden email]>:
> >>
> >> Hi Nikolay,
> >>
> >> Huge +1 for automated compatibility tests. Luckily, we already did that
> >> for
> >> persistence, so probably we can re-use some infrastructure from there.
> >>
> >> On Wed, Jun 6, 2018 at 1:20 PM, Nikolay Izhikov <[hidden email]>
> >> wrote:
> >>
> >> > +1 From me.
> >> >
> >> > As I wrote in previous mail-threads,
> >> > I think we need to create test framework to be able to test
> >> > compatibility
> >> > for all clients we have.
> >> >
> >> > AFAIK, currently, there is no possibility to automatically check
> >> > compatibility.
> >> >
> >> > В Ср, 06/06/2018 в 11:39 +0300, Vladimir Ozerov пишет:
> >> > > Igniters,
> >> > >
> >> > > I'd like to discuss once again our compatibility policy for thin
> >> > > clients
> >> > > (.JDBC, ODBC, .NET, Java, etc.). We have no clear rules for now, so
> >> > > let's
> >> > > try to come to agreement.
> >> > >
> >> > > Normally database vendors work as follows:
> >> > > 1) There is a set of currently supported database versions
> >> > > 2) There is a set of currently supported JDBC/ODBC drivers
> >> > > 3) Every supported driver can work with every supported database
> (with
> >> > > little exclusions to this rule).
> >> > >
> >> > > That is, they are both backward and forward compatible. I can take
> >> > > latest
> >> > > Oracle's JDBC and some ancient Oracle version, and it will work,
> >> > > unless
> >> > > this version reached EOL and is no longer supported. And vice versa
> -
> >> > > new
> >> > > database, old driver, all is fine.
> >> > >
> >> > > This is ideal scheme which I'd like to see in Ignite, but:
> >> > > 1) Our protocol is still relatively young and evolve rapidly
> >> > > 2) AI does not have any maintenance releases, so we cannot define
> >> > > which
> >> > > version is supported and which is not.
> >> > > 3)
> >> > >
> >> > > I'd like to propose the following compatibility policy:
> >> > > 1) Maintain forward and backward compatibility between two nearest
> >> > > minor
> >> > > releases only. E.g. 2.5 can work with 2.4, 2.6 with 2.5, etc.
> >> > > 2) Think of more strict compatibility rules in AI 3.0 because at
> this
> >> > point
> >> > > our protocol will be stable enough.
> >> > >
> >> > > Thoughts?
> >> > >
> >> > > Vladimir.
> >> >
>
>
>
> --
> Best Regards, Vyacheslav D.
>

[Pavel Tupitsyn]

Vladimir,

Not sure I see the point of 2 release policy.
It is not very good both for users and developers.

* Developers still have the burden on maintaining multiple protocol versions
* Users are quite limited with version choices

We should either go with a full-blown versioning so any client can work
with any server,
or don't bother with compat at all, IMO.

Pavel

On Wed, Jun 6, 2018 at 6:24 PM, Vladimir Ozerov <[hidden email]>
wrote:

> Igniters,
>
> Let's discuss how to implement tests in separate thread. At this point it
> is more important to agree on compatibility policies.
>
> On Wed, Jun 6, 2018 at 6:02 PM, Vyacheslav Daradur <[hidden email]>
> wrote:
>
> > Hello, Igniters!
> >
> > I am not familiar with the Ignite's thin client.
> >
> > I'd suggest defining tests scenarios first, to understand what we need
> > for testing.
> >
> > For example, our Compatibility Framework may be used for the following
> > scenario:
> > 1. Start node of a previously released version in separate JVM and fill
> > data;
> > 2. Start thin client of an actual version in local JVM then read and
> > validate data;
> >
> > Opposite scenario with new nodes and previously released thin clients
> > is possible too, but such tests will look difficult. If we need such
> > scenarios, may be required to extend frameworks API to simplify
> > coding.
> >
> >
> > On Wed, Jun 6, 2018 at 2:41 PM, Dmitry Pavlov <[hidden email]>
> > wrote:
> > > Hi Vyacheslav,
> > >
> > > WDYT about applicability of PDS compatibiltiy framework for thin
> clients?
> > >
> > > Sincerely,
> > > Dmitriy Pavlov
> > >
> > > ср, 6 июн. 2018 г. в 13:45, Vladimir Ozerov <[hidden email]>:
> > >>
> > >> Hi Nikolay,
> > >>
> > >> Huge +1 for automated compatibility tests. Luckily, we already did
> that
> > >> for
> > >> persistence, so probably we can re-use some infrastructure from there.
> > >>
> > >> On Wed, Jun 6, 2018 at 1:20 PM, Nikolay Izhikov <[hidden email]>
> > >> wrote:
> > >>
> > >> > +1 From me.
> > >> >
> > >> > As I wrote in previous mail-threads,
> > >> > I think we need to create test framework to be able to test
> > >> > compatibility
> > >> > for all clients we have.
> > >> >
> > >> > AFAIK, currently, there is no possibility to automatically check
> > >> > compatibility.
> > >> >
> > >> > В Ср, 06/06/2018 в 11:39 +0300, Vladimir Ozerov пишет:
> > >> > > Igniters,
> > >> > >
> > >> > > I'd like to discuss once again our compatibility policy for thin
> > >> > > clients
> > >> > > (.JDBC, ODBC, .NET, Java, etc.). We have no clear rules for now,
> so
> > >> > > let's
> > >> > > try to come to agreement.
> > >> > >
> > >> > > Normally database vendors work as follows:
> > >> > > 1) There is a set of currently supported database versions
> > >> > > 2) There is a set of currently supported JDBC/ODBC drivers
> > >> > > 3) Every supported driver can work with every supported database
> > (with
> > >> > > little exclusions to this rule).
> > >> > >
> > >> > > That is, they are both backward and forward compatible. I can take
> > >> > > latest
> > >> > > Oracle's JDBC and some ancient Oracle version, and it will work,
> > >> > > unless
> > >> > > this version reached EOL and is no longer supported. And vice
> versa
> > -
> > >> > > new
> > >> > > database, old driver, all is fine.
> > >> > >
> > >> > > This is ideal scheme which I'd like to see in Ignite, but:
> > >> > > 1) Our protocol is still relatively young and evolve rapidly
> > >> > > 2) AI does not have any maintenance releases, so we cannot define
> > >> > > which
> > >> > > version is supported and which is not.
> > >> > > 3)
> > >> > >
> > >> > > I'd like to propose the following compatibility policy:
> > >> > > 1) Maintain forward and backward compatibility between two nearest
> > >> > > minor
> > >> > > releases only. E.g. 2.5 can work with 2.4, 2.6 with 2.5, etc.
> > >> > > 2) Think of more strict compatibility rules in AI 3.0 because at
> > this
> > >> > point
> > >> > > our protocol will be stable enough.
> > >> > >
> > >> > > Thoughts?
> > >> > >
> > >> > > Vladimir.
> > >> >
> >
> >
> >
> > --
> > Best Regards, Vyacheslav D.
> >
>

[Vladimir Ozerov]

Pavel,

Agree. Looks like we should leave our compatibility policy as is and do not
limit it to several adjacent versions.

On Thu, Jun 7, 2018 at 12:35 PM Pavel Tupitsyn <[hidden email]> wrote:

> Vladimir,
>
> Not sure I see the point of 2 release policy.
> It is not very good both for users and developers.
>
> * Developers still have the burden on maintaining multiple protocol
> versions
> * Users are quite limited with version choices
>
> We should either go with a full-blown versioning so any client can work
> with any server,
> or don't bother with compat at all, IMO.
>
> Pavel
>
> On Wed, Jun 6, 2018 at 6:24 PM, Vladimir Ozerov <[hidden email]>
> wrote:
>
> > Igniters,
> >
> > Let's discuss how to implement tests in separate thread. At this point it
> > is more important to agree on compatibility policies.
> >
> > On Wed, Jun 6, 2018 at 6:02 PM, Vyacheslav Daradur <[hidden email]>
> > wrote:
> >
> > > Hello, Igniters!
> > >
> > > I am not familiar with the Ignite's thin client.
> > >
> > > I'd suggest defining tests scenarios first, to understand what we need
> > > for testing.
> > >
> > > For example, our Compatibility Framework may be used for the following
> > > scenario:
> > > 1. Start node of a previously released version in separate JVM and fill
> > > data;
> > > 2. Start thin client of an actual version in local JVM then read and
> > > validate data;
> > >
> > > Opposite scenario with new nodes and previously released thin clients
> > > is possible too, but such tests will look difficult. If we need such
> > > scenarios, may be required to extend frameworks API to simplify
> > > coding.
> > >
> > >
> > > On Wed, Jun 6, 2018 at 2:41 PM, Dmitry Pavlov <[hidden email]>
> > > wrote:
> > > > Hi Vyacheslav,
> > > >
> > > > WDYT about applicability of PDS compatibiltiy framework for thin
> > clients?
> > > >
> > > > Sincerely,
> > > > Dmitriy Pavlov
> > > >
> > > > ср, 6 июн. 2018 г. в 13:45, Vladimir Ozerov <[hidden email]>:
> > > >>
> > > >> Hi Nikolay,
> > > >>
> > > >> Huge +1 for automated compatibility tests. Luckily, we already did
> > that
> > > >> for
> > > >> persistence, so probably we can re-use some infrastructure from
> there.
> > > >>
> > > >> On Wed, Jun 6, 2018 at 1:20 PM, Nikolay Izhikov <
> [hidden email]>
> > > >> wrote:
> > > >>
> > > >> > +1 From me.
> > > >> >
> > > >> > As I wrote in previous mail-threads,
> > > >> > I think we need to create test framework to be able to test
> > > >> > compatibility
> > > >> > for all clients we have.
> > > >> >
> > > >> > AFAIK, currently, there is no possibility to automatically check
> > > >> > compatibility.
> > > >> >
> > > >> > В Ср, 06/06/2018 в 11:39 +0300, Vladimir Ozerov пишет:
> > > >> > > Igniters,
> > > >> > >
> > > >> > > I'd like to discuss once again our compatibility policy for thin
> > > >> > > clients
> > > >> > > (.JDBC, ODBC, .NET, Java, etc.). We have no clear rules for now,
> > so
> > > >> > > let's
> > > >> > > try to come to agreement.
> > > >> > >
> > > >> > > Normally database vendors work as follows:
> > > >> > > 1) There is a set of currently supported database versions
> > > >> > > 2) There is a set of currently supported JDBC/ODBC drivers
> > > >> > > 3) Every supported driver can work with every supported database
> > > (with
> > > >> > > little exclusions to this rule).
> > > >> > >
> > > >> > > That is, they are both backward and forward compatible. I can
> take
> > > >> > > latest
> > > >> > > Oracle's JDBC and some ancient Oracle version, and it will work,
> > > >> > > unless
> > > >> > > this version reached EOL and is no longer supported. And vice
> > versa
> > > -
> > > >> > > new
> > > >> > > database, old driver, all is fine.
> > > >> > >
> > > >> > > This is ideal scheme which I'd like to see in Ignite, but:
> > > >> > > 1) Our protocol is still relatively young and evolve rapidly
> > > >> > > 2) AI does not have any maintenance releases, so we cannot
> define
> > > >> > > which
> > > >> > > version is supported and which is not.
> > > >> > > 3)
> > > >> > >
> > > >> > > I'd like to propose the following compatibility policy:
> > > >> > > 1) Maintain forward and backward compatibility between two
> nearest
> > > >> > > minor
> > > >> > > releases only. E.g. 2.5 can work with 2.4, 2.6 with 2.5, etc.
> > > >> > > 2) Think of more strict compatibility rules in AI 3.0 because at
> > > this
> > > >> > point
> > > >> > > our protocol will be stable enough.
> > > >> > >
> > > >> > > Thoughts?
> > > >> > >
> > > >> > > Vladimir.
> > > >> >
> > >
> > >
> > >
> > > --
> > > Best Regards, Vyacheslav D.
> > >
> >
>