Brad King wrote: > I think Fraser's point about the docs of each policy not explicitly > mentioning "deprecated" is a major culprit there.
I disagree. It is obvious that NEW is better than OLD. If it 'works' people will use it until they are forced not to, as Alex said. I expect most people doing that are doing so in a well-informed way. The people getting help on SO and setting policies to OLD are in their first days/weeks of using cmake and probably seeing cmake documentation for the first time. It is not a good idea to use that as a reference scenario for us to make decisions. Even warnings won't prevent people relying on OLD behavior. They can still add -Wno-dev to a build script or alias (as is appropriate to do when building third party software). >> 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. It should be a simple pre-processor trick :). >> 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. I think the same is true of the existing design of policies. The WARN behavior of <= CMP0011 for the last six years is enough and we can error on them. > 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. Why? What kind of scenario are you thinking of that warnings are a benefit? What scenarios get the new CMake version into the hands of users who can do anything about them? I think making policies <= CMP0011 errors in CMake 3.4 is a benefit to all parties (maintainers of cmake, third party buildsystem maintainers, users of third party software, people doing user support). Those policy warnings are six years old. > 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. They are warnings. By default. What is the transition plan and what categories of third parties will and won't benefit from it? Thanks, Steve. -- 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
