ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexey Goncharuk <alexey.goncha...@gmail.com>
Subject [DISCUSS] Ignite 3.0 development approach
Date Mon, 02 Nov 2020 10:14:08 GMT

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


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