Bug 2380898

This should be filed against CMake as a regression there. This code requires no changes to build with either CMake >= 4.0 or <= 4.0. Rejecting a correct minimum version of 2.8 simply because CMake maintainers no longer like the old version (or whatever other reason they've come up with) is a bug.

The minimum version of CMake required is 2.8. 4.0 still works.

CMake should be fixed to not force incorrect minimum version updates.

With all due respect, no, this is not a CMake issue, and CMake will remove policies every 3 years. The policies are by definition deprecated behavior and these have been deprecated for more than 10 years.

As indicated in the Change proposal document, if upstream is dead or do not want to adapt, than add `CMAKE_POLICY_VERSION_MINIMUM=3.5` in the spec file. But the preferred action is to contribute upstream with a high higher bound policy in order to minimize future maintenance.

Yes, this is a CMake issue. Literally not a single change to the CMake file is required except updating the minimum version? Why? It works just fine with CMake 2.8 with no changes. It works just fine with CMake 4 with no changes (except requiring the code to lie and say that it needs 3.5 or later).

That is a CMake problem. There is no reason that this library should drop support for older distributions simply because CMake wants the code to no longer be compatible with it, even when the code is perfectly compatible with it. Forcing a client application to declare itself incompatible with older versions of a tool when it is, in fact, not incompatible with that tool, is a bug in the tool making that demand.

CMake policies control behaviors that have/had backwards compatibility. When you populate `CMAKE_POLICY_VERSION_MINIMUM=3.5` you *are* making changes to how a project builds. It just so happens, that the CMake policies are often very neiche so many projects are not affected by it. You *do* need to rebuild with the appropriate policies bumped to make sure that the project does not actually use those. One example is that `test`, `check`, etc. target names are reserved and when the cmake policies are bumped, the build might fail if it did use those.

> There is no reason that this library should drop support for older distributions

Nobody is asking you to do so and *this is not what is being proposed here*

Ask upstream to change to
```
cmake_minimum_required(VERSION 2.8...4.0)
``` 
This *maintains* compatibility with lower cmake versions and adds forwards compatibility for all CMake versions up to 4.0 (and beyond using older policy behavior).

If you do not wish to interact with upstream use the following
```
%build
export CMAKE_POLICY_VERSION_MINIMUM=3.5
%mingw_cmake -DBIBLESYNC_SOVERSION=%{__soversion}
%mingw_make
```
(but in the spirit of upstream first, the former approach is preferred)

FEDORA-2025-7e1da3d887 (mingw-biblesync-2.1.0-15.fc43) has been submitted as an update to Fedora 43.
https://bodhi.fedoraproject.org/updates/FEDORA-2025-7e1da3d887

FEDORA-2025-7e1da3d887 (mingw-biblesync-2.1.0-15.fc43) has been pushed to the Fedora 43 stable repository.
If problem still persists, please make note of it in this bug report.

I presume that the Copr repo will pick up the rebuild automatically on a scheduled build?