I’ve just started a petition…
I was told on Slack that this didn’t really need a petition, I could have just submitted a PR. But since both writing the code for this and submitting a PR are beyond me I’ll leave it there. I also found this a little confusing as I had assumed that every change had to go through the petition process.
And this comment was just made on Slack…
Minor changes do not need a petition. See ClassicPress Governance | ClassicPress
Whether this change in particular is a minor change is debatable, it sounds straightforward but quickly grew more complicated than expected. This is not going to make it into 1.1.0, there are several questions outstanding around how this should work by default and with various existing constants applied.
In particular, @williampatton has been talking to some business users who really need this to not be an option available to users, so that their content history remains fully auditable. From that perspective, just the presence of this option would be off-putting.
More generally, there are several very good reasons to use the petitions system, for which a PR or especially a Slack discussion is not adequate:
X was speaking specifically about business clients in the financial services sector.
This is a heavily regulated sector.
Audit trails are absolutely crucial.
For other clients, database size and optimal performance may be more important.
I propose:
This gets more into plugin territory.
Although I would propose considering it as a core plugin if it is written and put through some decent testing.
It would fit in well with the CP core value proposition to business users.
Yeah the 2 people I spoke to about this outside of CP were from financial sector which is regulated as far as they possibly can. They were not keen on seeing the option exposed for their kinds of uses (which may be minimal in terms of the actual CP target market). Thinking about them made me realise that we need to consider both exposing the option and making the option to expose it an option of it’s own. That extra complexity makes it a bit less appealing to implement.
My own personal opinion is that I DO WANT to see this exposed for end users.
The method where it could be set on a per-post basis sounds more preferable to having it set globally for all posts and post types site-wide. The example I though up for this is that for a privacy policy page I may want revisions retained indefinitely but blogposts may be fine with just 3 revisions (or for blogposts I may not care at all). Optionally we could add a per post-type default value and allow it to be filtered so that each post-type could have it’s own default set independently.
In my mind this kind of thing would be good to start as a plugin and then we could evaluate how useful it is and if we would want to roll the features back into core. There is additional complexity in managing this all in core (especially if it’s on a post-per-post basis) but I think that could be worked in as part of the next major version bump if it was indeed deemed suitable and useful to be directly in core.
Given this extra complexity this is no longer a minor change
This is why we have the petitions process, the direction for v2 has already been set. In the meantime:
Totally agree. When I asked some questions in Slack I did not expect this subject to reach that level of complexity 
I thought about that, too. So in my PR this option becomes readonly (if already defined in wp-config). That has sense because user can at least view current setting without digging in files and code. But at the same time the option still present and may be overriden/enabled any time by those, who have direct file access (e.g. devs).
And once there is no definition in config, option simply enables itself:
Yes, this quickly turned into something “not simple” - definitely not for 1.1. I still think we should do it as it fits the overall direction for CP, but it needs a little more thought first.
OK. I understand this is way more complex than I had imagined.
I was thinking along the same lines as @norske about this. So, the setting in config would act as an override. The default is to save all revisions, and display a setting so that the user could change it. BUT if the dev puts a line in the config file, then that takes priority over everything and the defined value is simply shown as an unchangeable display to the user.
Hmm… yes. Thanks Joy. That does exactly what I was proposing.
I guess I’m starting to agree that this is something that should be left for individual users to enable via a plugin.
I may have to down-vote my own petition. 
Using Optimize Database after Deleting Revisions – WordPress plugin | WordPress.org which also offers control over revisions on all my sites, CP and WP
I use Simple Revisions Delete – WordPress plugin | WordPress.org which allows me to choose which revisions to delete. This works because I like to save the oldest version of each post, along with the two most recent. And if I don’t want to delete revisions, it doesn’t do it for me.
