<html> <head> <base href="https://bugs.documentfoundation.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - Firebird-migration must happen only after user consent and advise to backup data prior to migration at 6.1" href="https://bugs.documentfoundation.org/show_bug.cgi?id=116944#c8">Comment # 8</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - Firebird-migration must happen only after user consent and advise to backup data prior to migration at 6.1" href="https://bugs.documentfoundation.org/show_bug.cgi?id=116944">bug 116944</a> from <a class="email" href="mailto:reisi007@gmail.com" title="Florian Reisinger <reisi007@gmail.com>"> Florian Reisinger</a> <pre>If (as currently built in) the content of the file is changed there is no way going back! If (in some way) the conversion is happening in a separate file, the user at least has the change of moving back to an older (probable insecure) release of LibreOffice. I guess we all agree that the currently implemented behavior is not in any way user friendly. It - in fact - will scare users away. However, especially if we have a release with both database drivers we can automatically compare the result of reports. Most read-only reports will change if executed not in the same moment. The hardest requirement would be to try converting to a new file and checking all reports and fail (or give a warning with the name of the reports) when the result are not identical. Only with such a dynamic test suite we would have a chance to make the transition as smooth as possible, I hope you agree to my statement that the current situation must not be released and that the conversation must happen to a new file. Some might complain that this is similar to introducing a new algorithm for encrypting documents, which also break compatibility with AOO and older versions of LibO. However the complexity of implementing / using a different encryption function cannot be compared to switching to a different database backend. Therefore a staged approach (marking Firebird non-experimental, creating new ODB files with Firebird, converting old databases OPTIONALLY, removing HSQLDB) should be spitted up to more than one maybe 3 or more releases. Bugs will appear and we need to fix them with the fewest impact for the user. A staged roll-out therefore is from the end user's point of view the only real option!</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>