On 06/08/2015 04:15 PM, Stephen Kelly wrote: > This isn't a 3.3 feature but a change to the documentation/release notes > which is supposed to be ok?
Yes, if the wording does not commit us to a specific future release. > I've changed the release notes to say 'some future release' instead. So, we > can figure that out on a per-Policy basis. Okay. Actually shouldn't the documentation of every policy say it may be removed in a future release? That is their general purpose. Perhaps that may help discourage projects from setting them to OLD. >> There could still be code paths that never set the >> minimum required version of CMake and therefore never set the policy >> to NEW. > > Will that ever not be the case? Of course project code may need to be fixed for this but I'm concerned about code paths within CMake itself. I'm pretty sure ctest and cpack both create cmake language contexts and may not always set the policy version. Things like that will come out of the woodwork when a change like this is made, and may not be noticed until project code activates them. >> Any refactoring that depends on removing support for OLD behavior >> needs to wait until after a release or two have removed it. We need >> to retain the possibility to revert the removal if major problems >> arise. I don't want the fallback to be "re-implement post-refactoring" >> because typically this may be revealed during a release candidate >> cycle. > > I think that's overkill for something like CMP0044 as I described in my > other mail. It would be easily re-added. This seems like something to apply > on a case-by-case basis. If for a specific case it is very easy to re-add post-refactoring then it could instead just be subsumed in the refactoring instead of removed. I'm saying that refactoring that is made possible only by removing a policy should not be done until after the policy removal is well- established as acceptable. Otherwise refactoring should preserve policies even if it is harder. -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers