Hi, Pavel! First of all, I'd like to clarify that the Compatibility Testing Framework was designed to work with a cluster of multi-version nodes. The main idea is to run a test to verify backward compatibility or do some kind of rolling upgrades.
It's not about persistence compatibility, but actually, it is used for this now. >> 1) It's uncomfortable to add and support new versions of Ignite product. I'm not sure what is a problem here? As I understand you suggest to do similar things - adding new pom.xml when new a version is released. Pay attention that not all tests should be tested on all versions, some test may want to test specific versions each other. >> 2) Manual maven dependency through java api. This is not about usability, it's about the framework's internals. If you have issues let's fix it and improve approach if needed. >> 3) It doesn't cover the case when some code which works on the current >> version will not work on older versions due to compile/runtime >> incompatibility. Please, describe the issue in more details? On Tue, Feb 19, 2019 at 7:55 PM Pavel Kovalenko <jokse...@gmail.com> wrote: > > Anton, > > >> What about the current compatibility framework? > Current compatibility framework will be removed after final adjusting to > new framework. > > >> Could you please share examples for each feature you mentioned? > You can see example in PR e.g. file > modules/compatibility/ignite-versions/2.1.0/pom.xml > <https://github.com/apache/ignite/pull/5974/files#diff-3c44ef223c31de9ff1e10bd7699cbcdc> > > I think such representing of Ignite product version is more cleaner than > existing approach with Java classes with dependencies and manual dependecy > management. > > >> Anyway. I don't like the idea to implement something new instead of > improving the existing. > If you have concrete proposals how to improve current framework please > share it. > > > вт, 19 февр. 2019 г. в 19:11, Anton Vinogradov <a...@apache.org>: > > > +5,327 −59 > > What about the current compatibility framework? > > I see no removal or updates. > > > > >> Each new version is represented by a single pom > > Sound not good. > > Could you please share examples for each feature you mentioned? > > > > Anyway. I don't like the idea to implement something new instead of > > improving the existing. > > > > On Tue, Feb 19, 2019 at 6:48 PM Pavel Kovalenko <jokse...@gmail.com> > > wrote: > > > > > Igniters, > > > > > > I would like to start a discussion about replacement existing > > > persistence compatibility test framework with the newer version. > > > The main purpose of that action is simplifying compatibility tests > > > development and support. > > > > > > The current version of the test framework has 3 disadvantages: > > > 1) It's uncomfortable to add and support new versions of Ignite product. > > > When a new version has released a developer must manually add new test > > > methods to all existing test suites to support the new product version. > > > 2) Manual maven dependency through java api. > > > If a new version of Ignite product has some specific dependency version > > > (like H2) a developer should take care about and manually cover this case > > > using java api. > > > 3) It doesn't cover the case when some code which works on the current > > > version will not work on older versions due to compile/runtime > > > incompatibility. > > > > > > A new version of the framework that is under development right now [1] > > > doesn't have such problems. > > > Here is a list of key features and possibilities: > > > > > > 1) One codebase - multiple versions support. > > > The key feature of the new framework is significant simplifying adding > > and > > > supporting the new versions of Ignite product. > > > Each new version is represented by a single pom file that contains Ignite > > > dependencies of specific version (core, indexing, etc.). All > > subdependecies > > > like H2 are covered by Maven automatically. > > > To add a new version for compatibility a developer just need to add a new > > > pom file with a new version of Ignite. All existing tests will > > > automatically detect the new version and will run tests against this > > > version without additional changes. This feature covers p. 1 and 2 of the > > > existing framework. > > > 2) Unified API to access and run code on old and new versions of Ignite. > > > Each of Ignite instance is represented by remote JVM with a single point > > of > > > interaction - running abstract closures. Each closure is just a class > > which > > > implement a "runner interface". Each closure object is serialized to a > > file > > > through Xstream library and executed on remote Ignite JVM. This approach > > > gives unified access to interact with both old and new versions of Ignite > > > and simplifies overall tests development. > > > 3) Ignite versions support for closures. Sometimes a closure couldn't be > > > run on newer or older Ignite version due to compile/runtime > > incompatibility > > > of that code. To resolve this problem a special annotation has > > introduced. > > > This annotation named as "@Since" contains minimal possible Ignite > > product > > > version where annotated closure can be compiled and run. Such closures > > are > > > processed on Ignite versions compile phase and this makes it possible to > > > use one closure for multiple Ignite versions without additional code > > > changes. Closures and versioning resolve p. 3 of the existing framework. > > > > > > [1] - https://issues.apache.org/jira/browse/IGNITE-11133 > > > > > > I would like to hear any opinions about the new framework. > > > > > -- Best Regards, Vyacheslav D.
