On 03/21/2013 08:29 AM, Stephen Kelly wrote: > When the try_compile source-file signature is used, it generates a > cmake_minimum_required line with the version of cmake run by the user (not > the minimum used by the project being built). > > This affects policies, and could have an effect on the generated > CMakeLists.txt file. Anyone using CMake master or next branch (eg the > dashboards and build.kde.org) does not currently get the version bump until > the final release is made, so any potential breakage resulting from this > issue would not be noticed until the final release is made.
Even with your proposal this would true during the entire development period until the release candidate cycle starts. It would be better for the policy to be able to become NEW right away. We used to do this by introducing policies with the version set to the current (dated) version of CMake. IOW, instead of using "2.8.11" as a policy's introduction version, one should use "2.8.10.20130203" or whatever date introduced it. We used to do this when introducing policies way back when. Then in the RC we bump the new policies' versions to the RC version. > The obvious way to me to resolve that is to merge release into master when > the RC cycle starts. Any reason not to? The entire point of the release branch is to hold the version number adjustments needed for release candidates. It should not be in master. I don't want to get into a debate about how the versioning works. -Brad -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
