This is awesome!

It really was too long since last official release. That did already cause many problems as new users often had problems that were solved many times in forum messages (and fixes to source) but solutions are often too hard to find with forum search.

I do agree that next goal would be the code cleanup. There are many routines that could be done better. Also subroutines that do same or almost same work could be combined.
While doing cleanup there becomes needs to change or add some properties but changes should be kept now small to get the core cleaned and stable.
I am sure that users always want to have some new properties but there are already so many that knowing and using all them starts to be hard.
After all these years I found out that there are still new properties to find for every now and then!

Also help side need refreshing. Using hastags (#) to separate topics inside same html file is not good idea as often used Linux substitute routine "xdg-open" that tries to find default web browser does drop hastags away making the whole system collapse. That makes important that user defines used browser path and name in prrferences/Program. And that is not a user friendly way.
It would also be nice to have assistance from a native English speaker to check the syntax although radio amateurs are used to understanding Hamglish language.

Maybe I am old-fashioned but I think we should encourage users to compile from source. That is always the best solution. And in case of Cqrlog it is not even hard.
We should have essentials-package (like for example flidigi has) that would load all needed tools to make a compile. The compile itself is not hard after all tools are present.

Of course all users do not want to do that and then the alternative could be Snap or Flatpack, but I am afraid that it would, how ever, make things more complicated for the maker of the package I.E. for Petr.

Third option could be a script install for those who do not want to compile. Many big vendors like HP (printers) use installation scripts for Linux.
In case of cqrlog the install by copying (script install) works perfectly if it is question of upgrading an existing Cqrlog. My test binaries install script has proven that.
With fresh new install an essentials-package for Cqrlog would be needed to support the script install. But that could be also created as series of package install commands inside the install script.

Making Cqrlog to use existing database server that exist there always at port 3306 when mysql/Maridb server is installed would make things easier to handle in future instead of trying to start another sql server instance using database inside the ~/.config/cqrlog folder.
Users just need a proper backup/restore routines then as copying the ~/.config/cqrlog would not be enough.
And also one-time-routine to move currently existing logs from ~/.config/cqrlog folder to "true" sql server running at port 3306.

Quite many things to think about and resolve for Cqrlog 2.6.0 !

Meanwhile, let's enjoy now for long awaited version 2.5.0!