[cmake-developers] A policy for Policies

[Brad King]

On 07/01/2015 02:17 PM, Stephen Kelly wrote:
> Brad King wrote:
>> We need to provide such capabilities so authors that do maintain
>> their projects can be confident they've ported away from behavior
>> that will later become an error.
> 
> Makes sense to me.

I see topic end-Policy-lifetime with commit range e7fbd489..c7512801
currently in 'next', but it doesn't have anything about making things
into errors early.  I thought we agreed to build that infrastructure
first.  I guess POLICY_WARNING and POLICY_OPTIONAL_WARNING are a step
in that direction but I'd like to see the actual error options be
available before we start showing the warnings unconditionally.

> I think the warning should indicate which version of CMake introduced the 
> policy (already the case) and the date that was released. This might provide 
> the information needed to prioritize that Alex was looking for by instead 
> asking for the date it would become an error.

The problem with such dates is when the policy is introduced we don't
know the date of the next release.  Even if we had some kind of lookup
table maintained as releases are made, the wording of policy messages
would then change as a release is made, which is not great for testing.

>> Let's skip these for 3.4 and see how the warnings for the 14 policies
>> in the above and below groups work out.
> 
> The reason I suggested emitting these unconditional warnings is that we 
> should establish what the lifecycle of policies actually is.

No.  My view throughout the conversation in this thread is that we don't
know an appropriate length for the lifecycle.  We should start by assuming
it is longer than some of the oldest policies (e.g. CMP0011) and working
our way forward through time.  That will let us see how projects handle
steps of the lifecycle without aggressively warning even on recently valid
code.

The lifecycle proposed in commit d5b1839a is way too aggressive.  The
end-Policy-lifetime topic looks nothing like the schedule or selection
of policies discussed in the last few messages of this thread.

> Setting a policy to OLD is not designed to be a convenience for the
> maintainer of the project, who can schedule appropriate handling of
> the policy.

Originally it was intended to be exactly that.  Not all projects
are maintained on the same release schedule that CMake has.  If they
release only once per year then CMake could be deep into a policy
lifecycle as proposed in d5b1839a.  Many people skip a few CMake
releases at a time and may jump over some of the steps.  I think
step 2 of that schedule should be at least 3 releases after step 1,
but we don't really know yet what the schedule should be as mentioned
above.

All we've agreed upon in this thread is that 3.4 can emit unconditional
warnings for CMP0011 and below and also CMP0024 and CMP0026 (since those
are the ones we really want to get rid of and may be frequently set to
OLD).  Also it should come with options to make the warnings into errors
so they are easier to find.

-Brad