some kind of backward compatibility [was: Update to Firebird 3.0]

[Lionel Elie Mamane]

On Fri, Jun 10, 2016 at 01:34:00PM +0200, Bunth Tamás wrote:
>> Well, old odb files do not use the archive format... That's what
>> brings the endianess issue.

> So what do you suggest? I searched for the --with-fbsecure-db option
> in the fb 2.5 version, and the 2.5 version has this option too. So I
> think I can make the archive file before updating the "update to fb 3
> part".

> I say this, because it may be a solution for the older odb files if
> there would be a Libreoffice version, where LO saves database as an
> archive file, but with fb 2.5. And fb 3.0 should be used in a LO
> version after that. Is that a possible way?


Aha, I see that Firebird 3.0 cannot open older non-backup files, but
that a future 3.x version will. If that future version comes fast
enough, it solves our problem.

Else, we have to think. Given the difficulties to compile fb 2.5 with
a modern Microsoft Visual C++ compiler, I'd like to avoid carrying
along firebird 2.5 any longer than strictly necessary.

The possibilities:

 - Use your plan to release one LibreOffice version with fb2.5 and
   archive format. I don't like it that much. We break forward
   compatibility when we switch to the archive format. We need to
   patch fb2.5 to compile with a modern MSVC.

 - Ship (embed) both firebird 2.5 and 3.0 and use the embedded fb2.5
   only to do the gbak dump, and load the result with firebird 3.0.
   We break forward compatibility but avoid to wait for two LibO
   release cycles.

 - We make a utility separate from LibO that converts the fb2.5 data
   to archive format within an odb. We can even compile that utility
   (and fb2.5) with an older MSVC and be done with it. Or we "require"
   a system-installed firebird 2.5. Hum.

   Not the most user-friendly, but IMO technically sound. Tamás, do
   you feel like you could write such a GUI stand-alone tool?

 - We cop out and say the Firebird was an experimental feature
   anyway.

-- 
Lionel