Denis, the argument sounds convincing to me. When you use 3rd party DB, you rarely have to care how to migrate DB data.
Igniters, I suggest keeping compatibility as long as we can, even with the transition to a new major release. If incompatibility will become unavoidable we will consider migration procedures. чт, 21 сент. 2017 г. в 0:21, Denis Magda <[email protected]>: > Either 3 or 4 looks as an appropriate approach for me. Ignite is no longer > just an in-memory storage and we can not afford to force our users to > migrate the data or configuration just because of the new cool feature in a > new version. We should provide the same level of compatibility as RDBMS > vendors do. > > — > Denis > > > On Sep 19, 2017, at 4:16 AM, Vladimir Ozerov <[email protected]> > wrote: > > > > igniters, > > > > Ignite doesn't have compatibility for binary protocols between different > > versions, as this would make development harder and slower. On the other > > hand we maintain API compatibility what helps us move users to new > versions > > faster. > > > > As native persistence is implemented, new challenge appeared - whether to > > maintain binary compatibility of stored data. Many approaches exist: > > > > 1) No compatibility at all - easy for us, nightmare for users (IMO) > > 2) No compatibility, but provide migration instruments > > 3) Maintain compatibility between N latest minor versions > > 4) Maintain compatibility between all versions within major release > > > > The more guarantees we offer, the harder them to maintain, the better UX. > > > > Let's think on what compatibility mode we can offer to our users if any. > > Any ideas? > > > > Vladimir. > >
