ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pavel Tupitsyn <ptupit...@apache.org>
Subject Re: Thin clients compatibility policy
Date Thu, 07 Jun 2018 09:35:53 GMT
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 <vozerov@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 <daradurvs@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 <dpavlov.spb@gmail.com>
> > wrote:
> > > Hi Vyacheslav,
> > >
> > > WDYT about applicability of PDS compatibiltiy framework for thin
> clients?
> > >
> > > Sincerely,
> > > Dmitriy Pavlov
> > >
> > > ср, 6 июн. 2018 г. в 13:45, Vladimir Ozerov <vozerov@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.
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message