Re: Thin clients compatibility policy

[Vladimir Ozerov <vo...@gridgain.com>]

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 <pt...@apache.org> 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 <vo...@gridgain.com>
> 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 <da...@gmail.com>
> > 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 <dp...@gmail.com>
> > > wrote:
> > > > Hi Vyacheslav,
> > > >
> > > > WDYT about applicability of PDS compatibiltiy framework for thin
> > clients?
> > > >
> > > > Sincerely,
> > > > Dmitriy Pavlov
> > > >
> > > > ср, 6 июн. 2018 г. в 13:45, Vladimir Ozerov <vo...@gridgain.com>:
> > > >>
> > > >> 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 <
> nizhikov@apache.org>
> > > >> 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.
> > >
> >
>