Re: [Discussion] Persistence compatibility framework refactoring

2019-02-23 Thread Vyacheslav Daradur
Pavel, >> A new version of Ignite has released and a developer should update >> compatibility tests to run it against the new version. Now I think that understand a problem which you are trying to solve, but I'd suggest another solution: In unit-testing world such problems usually is solved simil

Re: [Discussion] Persistence compatibility framework refactoring

2019-02-20 Thread Dmitriy Pavlov
Just a reminder: Veto is valid with justification. I see no reasons either (need some time to dive into details), but it is not a reason for a veto. ср, 20 февр. 2019 г. в 16:39, Anton Vinogradov : > Dmitriy, > > Please stop chilling community :) > No one makes final decisions here. > Please make

Re: [Discussion] Persistence compatibility framework refactoring

2019-02-20 Thread Anton Vinogradov
Dmitriy, Please stop chilling community :) No one makes final decisions here. Please make sure you've got my position before chilling :) I see no arguments to replace one solution with another. In case no real reasons will be provided this merge will gain my Veto, just a warning... On Wed, Feb 2

Re: [Discussion] Persistence compatibility framework refactoring

2019-02-20 Thread Nikolay Izhikov
Dmitriy, > So I suggest chilling a couple of days without any discussion. Why you trying to stop regular, positive dev-list discussion? I think, we should have a strong reason to throw away some subsystem and completely rewrite it. We will damage product robustness with it. >> 1. Automatic test

Re: [Discussion] Persistence compatibility framework refactoring

2019-02-20 Thread Dmitriy Pavlov
Hi, please do not rush to make any final decision. I think we all need some time to think about these 2 solutions. So I suggest chilling a couple of days without any discussion. Later we can come back to this topic and dive into it once again, maybe we can merge it into one taking the best parts

Re: [Discussion] Persistence compatibility framework refactoring

2019-02-20 Thread Anton Vinogradov
>> 1. Automatic tests scaling for new versions. >> 2. Automatic dependency management. Let's just improve the current solution. See no problems here. You'll have my *Veto* on merge without real reasons to replace solution instead of improvement. On Wed, Feb 20, 2019 at 3:55 PM Pavel Kovalenko wr

Re: [Discussion] Persistence compatibility framework refactoring

2019-02-20 Thread Pavel Kovalenko
Anton, In my first message, I already noticed the usability problems of the current framework and showed how they can be solved using the new framework. It gives us 2 major advantages: 1. Automatic tests scaling for new versions. 2. Automatic dependency management. Described approach simplifies te

Re: [Discussion] Persistence compatibility framework refactoring

2019-02-20 Thread Nikolay Izhikov
Hello, Pavel. Please, clarify. What exactly your new compatibility framework should check? I know at lease 2 compatible subsystem in Ignite that should work with previous versions: 1. Persistence. 2. Thin client. > A new version of Ignite has released and a developer should update compatibility

Re: [Discussion] Persistence compatibility framework refactoring

2019-02-20 Thread Pavel Kovalenko
Vyacheslav, Thank you for answers! >> I'm not sure what is a problem here? At the moment it's a little bit hard to understand the impact of such a change because the number of test suites is small. Let's Imagine you have X compatibility test suites where X is a relatively big number, let's say 20

Re: [Discussion] Persistence compatibility framework refactoring

2019-02-20 Thread Anton Vinogradov
Fully agree with Slava, Pavel, please share your vision of compatibility framework (current and desired). It really looks like you don't love current just because you can't understand how to use it properly. But this should not mean we have to remove the current, we should improve/refactor/documen

Re: [Discussion] Persistence compatibility framework refactoring

2019-02-19 Thread Vyacheslav Daradur
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 actu

Re: [Discussion] Persistence compatibility framework refactoring

2019-02-19 Thread Pavel Kovalenko
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.

Re: [Discussion] Persistence compatibility framework refactoring

2019-02-19 Thread Anton Vinogradov
+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

[Discussion] Persistence compatibility framework refactoring

2019-02-19 Thread Pavel Kovalenko
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