# User defined policies
**URL:** https://discourse.cmake.org/t/user-defined-policies/899
**Category:** Development
**Created:** [April 1, 2020, 6:16am UTC](https://discourse.cmake.org/t/user-defined-policies/899 "2020-04-01T06:16:56Z")
**Posts on this page:** 5
**Page:** 1
### Author:  [@zaufi](https://discourse.cmake.org/u/zaufi)
#### Post date: [April 1, 2020, 6:16am UTC](https://discourse.cmake.org/t/user-defined-policies/899/1 "2020-04-01T06:16:56Z")
Hi,
I have a quite big CMake “framework” used internally in many projects. Now I faced w/ necessity to have smth similar to CMake’s policies – e.g., I want to change behavior of some functions in a backward-compatible way, or use only a new behaviour if it set by a policy… That needed because with every new version of the framework containing breaking changes there are some project that is hard to migrate right now, but some features from the new release are critical to use ASAP.
I’ll be nice to have an ability to register project specific _User Defined Policies_ somehow and manage 'em in the way of `CMPxxxx` with `cmake_policy` command.
Thoughts?
---
### Author:  [@brad.king](https://discourse.cmake.org/u/brad.king)
#### Post date: [April 1, 2020, 10:49am UTC](https://discourse.cmake.org/t/user-defined-policies/899/2 "2020-04-01T10:49:56Z")
Policies are defined w.r.t. CMake versions so using `cmake_policy` won’t make sense for your framework’s policies because it is versioned separately. Instead you could implement your own mechanism in the framework following the same approach. You just need a way for clients to express the minimum version of your framework that they require and perhaps the maximum version of your framework for which they have been updated. From that you can adjust behavior accordingly.
---
### Author:  [@ben.boeckel](https://discourse.cmake.org/u/ben.boeckel)
#### Post date: [April 1, 2020, 12:00pm UTC](https://discourse.cmake.org/t/user-defined-policies/899/3 "2020-04-01T12:00:32Z")
> [@brad.king](#):
>
> You just need a way for clients to express the minimum version of your framework that they require
`find_package(framework 1.0)` is a good place to get that from. VTK and ParaView does this for their old `${VTK_USE_FILE}` compat ([https://gitlab.kitware.com/vtk/vtk/-/blob/master/CMake/vtk-config.cmake.in#L283](https://gitlab.kitware.com/vtk/vtk/-/blob/master/CMake/vtk-config.cmake.in#L283)).
Note that one thing you can’t easily emulate is CMake’s policy scope logic. You’ll just have to persist the requested version in the `find_package` scope…but then there’s only ever a single impl of your API functions since functions are global and never directory scoped.
---
### Author:  [@zaufi](https://discourse.cmake.org/u/zaufi)
#### Post date: [April 1, 2020, 12:06pm UTC](https://discourse.cmake.org/t/user-defined-policies/899/4 "2020-04-01T12:06:23Z")
Yep, the scope of variables could be a problem…
The point is not only in used versions, but about particular features of the release… E.g., I have a function with changed behaviour and I’d like to have some way to express the necessity to keep the old behaviour … maybe smth like:
```cmake
cmake_policy(GET UDP001 var)
if(var STREQUAL "NEW")
...
```
so the clients of that function may just set `UDP001` to desired value and don’t bother about the scope…
---
### Author:  [@brad.king](https://discourse.cmake.org/u/brad.king)
#### Post date: [April 1, 2020, 12:19pm UTC](https://discourse.cmake.org/t/user-defined-policies/899/5 "2020-04-01T12:19:07Z")
This is not something I’d like to add to CMake’s policy mechanism.
For individual features of your framework you can just ask projects to set a variable to control the behavior. When the variable is not set then check the version range I mentioned above to determine whether the project is aware of the current version of the framework.