You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
KeePass 2.35 introduced a neater way to store our plugin custom data. This necessitates the use of the kdbx4 file format.
Wait for a new KeePass release to indicate broad support for the kdbx4 format among major KeePass ports.
Bump minimum supported KeePass version to 2.35.
Implement a new KeePassRPC feature to migrate all custom data to the new format and delete the old advanced strings.
Trigger this feature automatically if the database is saved into kdbx4 format by KeePass.
(optional): Allow user to trigger the feature manually if they are running a version of KeePass > 2.35 but lower than the hypothetical version that forces saving into kdbx4 format.
The text was updated successfully, but these errors were encountered:
I've not seen anything to say that kdbx4 is now widely supported by KeePass 2 ports. So perhaps we should adjust the plan to avoid the automatic triggering of the migration but instead have a feature setting of whether to use the CustomData or Advanced String. We could default to CustomData for new databases (or databases with no KeePassRPC configuration already present) but otherwise only change the storage location for existing and new entries if the user makes a change to the setting.
Still, if there is a high chance that many new users will have to change this setting after experiencing cross-application data loss we might want to wait even longer than we already have.
We'll enforce this new storage location in KeePassRPC v2. There won't be any opt-out but we will keep the old string configuration around for at least a while, to make rollback even easier if anyone finds they have to stay on the older KeePassRPC version for a short time while compatibility issues are addressed. See also #143
KeePass 2.35 introduced a neater way to store our plugin custom data. This necessitates the use of the kdbx4 file format.
The text was updated successfully, but these errors were encountered: