Firebird not experimental

[Mike Kaganski]

On 27.08.2024 19:48, Robert Großkopf wrote:
> Hi *,
>>
>> Moreover
>>
>> 1) we still use FB 3.0.7 whereas 2 major releases have been published 
>> (4 and 5) and version 6 is in dev.
>>
>> At minimum, we should upgrade to version 5 to avoid trying to fix 
>> bugs on a old FB version.
>
> What would happen with all the old Firebid databases then? Might be a 
> good idea first to put to newest version and then to set non 
> experimental, but there are many people already using internal 
> Firebird and it should work without any problems when changing version 
> of LO (and changing Firebird-version this way).

IMO, the requirement to upgrade to FB 5 before moving it out of 
experimental status is reasonable. Even though the change *should* be 
backward-compatible (we keep the embedded DB in backup format, and it is 
expected that backups of any older FB version are read by newer FB 
versions, so the expectation is to have the older DB silently upgraded 
to newer FB version), it won't be forward-compatible (older LO versions 
will be unable to read ODBs created / upgraded by newer LO versions). So 
minimizing this, having the upgrade in work 
(https://gerrit.libreoffice.org/c/core/+/168449), is important to avoid 
another bad impression of "the just-introduced functionality gets 
incompatible (in one way) already in the next release".

On the other hand, it is OK to rely on this backward compatibility of 
the experimental feature, and *not* require that "it should work without 
any problems when changing version of LO" - when version changes from 
newer to older (again, changing from older to newer is expected to work 
automatically).

>>
>> 2) what about the existing odb with HSQL Embedded, should we propose 
>> migration towards FB each time knowing there are still quite some 
>> bugs about it?
>
> I would prefer to add a special switch like "don't ask again". So old 
> HSQLDB still would exist

Note how Juan explicitly addressed that in the very first mail:

On 27.08.2024 0:06, Juan C. Sanz wrote:
>
>
>       HSQLDB Migration
>
> According to TDF#116968 
> <https://bugs.documentfoundation.org/show_bug.cgi?id=116968>/(Database-Firebird-Migration) 
> - [META] Migrating existing embedded HSQLDB databases to 
> Firebird/,there do not seem to be any serious problems preventing its 
> use, but in any case, the migration process should not be automatic, 
> in my point of view. Very few databases offer a migration process from 
> one database to another, unless there is a commercial and/or economic 
> interest in doing so.
>
> That is why the migration process should not be proposed in such an 
> invasive way when you open a HSQLDB database and at the same time you 
> are using Firebird (because you have activated the experimental 
> functions). This process could be associated to a wizard or an 
> independent menu option.
>
>
>       Proposal
>
> In considering the above, I propose to the ESC (or whomever it may 
> concern):
>
>  *
>
>     ...
>
>  *
>
>     Decouple HSQLDB migration from the existence or not of Firebird.
>
I totally agree, that the migration shouldn't be suggested at opening 
*at all*, never; if the migration functionality is wanted kept at all 
(which I personally doubt), then it should be some "tool" available in a 
menu, for those who, for some reason, want and look for it. The end goal 
of dropping HSQLDB from the package should be re-considered, and IMO 
should not happen - just have it for compatibility, indefinitely (the 
idea was to avoid Java dependency, but when there is an alternative of 
FB, especially made the default, it's no more of a dependency than for 
Java macros / extensions; and we have much more pressing Java dependency 
in the report builder).

I support moving FB out of experimental ASAP (after FB5 upgrade). And 
indeed, it is expected that we get more bug reports after that - it's 
normal in any project, and especially so in our, with time-based releases.


-- 

Best regards,

Mike Kaganski