Igniters,
The compatibility testing framework [1] will be completed soon.
We will be able to cover all the cases suggested by Vladimir, for example:
>> 2) No compatibility, but provide migration instruments
It will be possible to test migration tools and scenarios provided to the
end users.
Some usual steps:
* start(2.2), putAll(data), stop(2.2) - working with previous versions
of Ignite cluster;
* startMigration(...) - migration using provided tools;
* start(curVer), checkAll(data) - data validation;
>> 3) Maintain compatibility between N latest minor versions
Every change triggers compatibility test update, so, the latest version
will be compatible with a previous format. It will be possible to perform
cascade update (eg. 2.2 -> 2.6 -> 2.9):
* changes in 2.3 -> add unit tests to check compatibility with 2.2;
* changes in 2.7 -> rewrite previous unit tests to check compatibility
with 2.6;
* changes in 2.9 -> rewrite previous unit tests to check compatibility
with 2.8;
* etc.;
* major release -> delete all compatibility tests, for example, for the
version 3.0;
>> 4) Maintain compatibility between all versions within major release
Every change triggers compatibility test creation, so, the latest version
will be compatible with every previous within major release:
* changes in 2.3 -> add compatibility unit tests with 2.2;
* changes in 2.7 -> add compatibility unit tests with 2.6;
* changes in 2.9 -> add compatibility unit tests with 2.8;
* etc.;
* major release -> delete all compatibility tests, for example, for the
version 3.0;
[1] https://issues.apache.org/jira/browse/IGNITE-5732 - Provide API to test
compatibility with old releases
On Tue, Sep 19, 2017 at 8:06 PM, Valentin Kulichenko <
[email protected]> wrote:
> In my view, there are two different scenarios.
>
> First - user just upgrades the version (to get some bug fix, for example),
> but does not intend to change anything in their project and/or use any new
> features. In this case it should work transparently and cluster must be
> able to work with older format. Ideally, we should detect this
> automatically, but if it's not possible we can introduce some kind of
> 'compatibility mode' enabled by a system property.
>
> Second - user upgrades to get new features that require data format change.
> In this case, I think it's OK to suggest using a conversion tool. Or
> probably we can apply it automatically on node startup?
>
> -Val
>
> On Tue, Sep 19, 2017 at 6:38 AM, Yakov Zhdanov <[email protected]>
> wrote:
>
> > >Any major change in data/index page format. E.g. this could happen once
> > transactional SQL is ready.
> >
> > I would suggest we automatically disable this feature for databases
> created
> > with older versions.
> >
> > --Yakov
> >
>
--
Best Regards, Vyacheslav D.
