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 <ptupit...@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 <voze...@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 <daradu...@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....@gmail.com> > > > wrote: > > > > Hi Vyacheslav, > > > > > > > > WDYT about applicability of PDS compatibiltiy framework for thin > > clients? > > > > > > > > Sincerely, > > > > Dmitriy Pavlov > > > > > > > > ср, 6 июн. 2018 г. в 13:45, Vladimir Ozerov <voze...@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 < > nizhi...@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. > > > > > >
