The library uses its own variable for settings storage, at least in fvignoredversions.cpp (autoupdate branch). When an application uses the library, it might end up storing settings in two different places: one for application settings (if it stores them, for example, in IniFormat), one for Fervor.
I believe this is harder to understand, to maintain and to configure after deploy, than in case where application provides Fervor library with settings variable. The application author would then be free to decide how he wants to store settings, he wouldn't have to comply with library requirements.
I propose to roll back the commit c76d4bc0aa83c24027155773cbcecd1b1beb6a63 ("reinstate access to QSettings to store ignored version").
The library uses its own variable for settings storage, at least in fvignoredversions.cpp (autoupdate branch). When an application uses the library, it might end up storing settings in two different places: one for application settings (if it stores them, for example, in IniFormat), one for Fervor. I believe this is harder to understand, to maintain and to configure after deploy, than in case where application provides Fervor library with settings variable. The application author would then be free to decide how he wants to store settings, he wouldn't have to comply with library requirements. I propose to roll back the commit c76d4bc0aa83c24027155773cbcecd1b1beb6a63 ("reinstate access to QSettings to store ignored version").