This could be as simple as having a "Deprecated" folder in the templates and putting them all there?

And in order to keep this list sane, we can remove policies older than X releases.

+Lutz since he has been messing recently with that.
+Owen for info and possible ideas.

I like the idea of having a 'Deprecated' folder. It's easy to implement (<<1 day) and gives the admins a way to see what's changing and allows them to take action.

Besides 'Deprecated' (still working, but planned to be removed), I'd also add 'Unsupported' (policies not working anymore).

I'm not even sure if we need to remove very old policies any time soon. Right now, I could 49 policies marked deprecated compared to 381 total policies. We could probably go on for a decade until the list grows too big.

That count seems very reasonable, so makes sense to not trim yet.

I wasn't aware of the distinction between deprecated and unsupported. From my understanding, deprecated means not available anymore (in current Stable). Is that not the case? From the documentation, every policy marked as deprecated shows a last version where it's supported.

Not every deprecated policy has a last supported version, e.g. 'DisabledSchemes' or 'JavascriptEnabled', so I came up with the interpretation that it must be the distinction between 'deprecated' and 'unsupported'. I'm not sure, though. I'll ask Julian tomorrow.

We should definitely add documentation for the 'deprecated' flag, when to use it and what it does (I believe it just removes policies from docs and templates).

To make things clear here (in case some other readers doesn't know):
There're two ways to deprecate a policy.
1) Deprecated flag (i.e. https://www.chromium.org/administrators/policy-list-3#SigninAllowed)
This will removed the policies from ADM/ADMX file but not the html documentation.
The policy will be marked as 'This policy has been deprecated' in chrome://policy and might still work.

2) Last supported version (i.e. https://www.chromium.org/administrators/policy-list-3#ChromeFrameRendererSettings)
This will remove the policies from ADM/ADMX file and html documentation. (As  crbug.com/770874 )
The policy will be marked as 'Unknown policy' in chrome://policy and won't work for sure.

I think the main difference here is the first deprecated will still works for the admins who have already used it. The second deprecated is a truly dead policy. There're around 20+ dead policies on desktop. (There're some more for ChromeOS and IOS). Some policies are deprecated by both two ways.

I agree it is good to have a 'deprecated' folder for first deprecation. As these policies are still read by Chrome, admin may want to change the value of them. The only concerns I have is it might 'encourage' people looking into these policies. (I know some of them really want that SigninAllowed). Maybe we should at least add some warning in the policies description/summary says these policies are deprecated and only remains for backward compatibility. We're not maintain them anymore and may remove them in the future.

I'm not sure about the dead one a.k.a. 'unsupported' one. It doesn't make sense to me that showing a policy that is not working anymore. We might just move them to a separate templates for the admin who just want to do the cleanup.

==================================================================================

FYI, we have very similar situation for unreleased policy. We have future flag and first supported version. We could also has 'beta'/'dev' folder for the future flag.

Thanks zmin, that makes sense to me now.

This bug has an owner, thus, it's been triaged. Changing status to "assigned".