On 06/09/2015 07:06 PM, Stephen Kelly wrote: > The problems are that we have no defined lifecycle for a Policy
Agreed, and that's what this thread is about. > even greenfield projects starting their project with CMake 3.2 - see the > policies as feature toggles. I think Fraser's point about the docs of each policy not explicitly mentioning "deprecated" is a major culprit there. Even those that did read the policy documentation referenced by warnings were not told before that OLD means deprecated. The documentation update I made for that may help with future perception. > Policies should issue 'unconditional' warnings in time frames of > less than 6 years. Yes. > 1) Three releases after introducing a Policy, we make OLD the same as WARN > for it. That is, the only way to not get the warning will be to fix the > code or use -Wno-dev. Yes. We could also look at making this automatic in the implementation of each policy by checking the version number or some internal release counter. That way we don't have to remember to update old policies. > 2) After some time in years (depending on the impact of the Policy), we > change it to an unconditional error. > 3) Remove the code implementing the OLD behavior in a following release. If OLD behavior is an unconditional error then there is no reason not to remove its implementation immediately in the same step. The old code could not possibly be covered by the test suite anyway. The presence of the warning from step (1) will mean projects should have long ported away from encountering the error. > My suggestion is similar to yours except that mine introduces the no-OLD > implementation closer to the introduction of the Policy rather than close to > the removal of it. Yes, I like that better. > That will achieve the goal of allowing projects to silence the warning when > they're close to their own release, and the goal of encouraging fixing code > away from OLD behavior in a timely manner. Good. > We should also apply this retroactively and make CMake 3.4 issue warnings > for policies introduced in 3.1 and earlier. Yes, though see below for an alternative schedule for transition to this policy sunset approach. > I've pushed a branch for testing which updates the policies <= CMP0011 to > REQUIRED_IF_USED. Those have resulted in warnings by default for 6 years. > That is a long time to ignore warnings. > > The projects this will potentially affect negatively are the projects > which have been unmaintained for 6 years. Projects that have been maintained but set policies to OLD will also be affected. Such projects need to be able to see warnings for a few releases first. We need a transition plan that does not jump straight to making things errors in 3.4 even for the oldest policies because they are not even warnings right now. Side note: We also need infrastructure to catch policy warnings within our own test cases. Several tests have policy warnings right now that go unnoticed because no one reads the output of passing tests. --------------------------------------------------------------------- In order to test the waters of this approach I think we should start by placing policies <= CMP0011 into step 1 by adding warnings for use of OLD behavior in 3.4. Then in each following release play catch-up by adding warnings for policies introduced in the next two or three oldest releases. This will soften the blow by not adding dozens of new warnings in a single release. Depending on the reaction to such warnings in 3.4 we can decide on a schedule to remove the ancient policy OLD behavior altogether. -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