Igniters, I wanted to pitch a rather radical idea regarding the Ignite 3.0 development which has occurred to me some time ago.
We already have several IEPs targeted to Ignite 3.0 which imply major changes to the codebase (the change in replication protocol and thus transactions, change in binary format, updated metastorage, etc). We also planned significant changes in public APIs: configuration format change, improvements in cache APIs, SQL APIs, transaction mode rework. The wishlist of changes for Ignite 3.0 is huge. So, I was wondering whether it makes sense to try to change the old codebase, or start with a new baseline and move old pieces of code that do not require significant rework. Personally, I would go with the second option for the following reasons: - We have a chance to shift the development paradigm in the project and introduce the practice of true unit-tests. In the new baseline at the beginning there will be no ability to run an end-to-end scenario, thus we will be forced to write unit-tests. So far, such practice was hard to implement because of tight coupling between Ignite components and inability to instantiate components without an instance of KernalContext. For example, we should be able to thoroughly test internal primitives, such as replication protocol (without actual communication), distributed metastorage contracts, persistence layer, etc. - We will significantly reduce the development cycle in the beginning (right now the RunAll takes two hours of astronomical time with empty TC; in the new approach developer will be able to run ALL tests locally in a matter of minutes) - We can get rid of TC bot and enforce green TC by integrating TC build results with GitHub PRs (the same way Travis is currently integrated to PR check). We should restrict PR merge without a TC check - We will still have to re-write all tests, but only once. If we try to modify the old codebase, we would need to modify all the tests for every major change (public API change, configuration change) - We will have fewer conflicts when working together. For example, I cannot imagine how one would merge two changes of getting rid of IgniteFuture and changes in replication protocol, for example Technically, I would suggest creating a new repository for Ignite 3.0 (perhaps, a new clean branch, but a new repo looks nicer to me) and a new Ignite 3.0 TeamCity project. While it may seem quite radical, I do believe that this approach will give us more benefits than trying to make such major changes in the existing codebase. If needed, let's schedule a discord chat like before to discuss this. WDYT?
