id,summary,reporter,owner,description,type,status,priority,milestone,component,version,severity,resolution,keywords,cc,focuses 48953,Improved revision control related to posts and the numerous auxiliary benefits,carike,,"Imagine for a moment, the Gutenberg full-site editing capability is in full swing: - How does a user restore defaults? - How does a user easily undo actions? - How does a user easily go back to a previous theme? - If the user deletes a theme, how can all the associated custom post versions for that theme be deleted as well? That (and more) could be easily achieved if posts revisions worked in a different way. In the Gutenberg full-site editor example above, each theme could create a ""branch"" of revisions. There would then be major and minor versions. I propose that the default should be to keep all major versions (unless the user manually deletes them of course), as well as all minor versions since the last major version up to the current version. This would allow for the user to ""back space"" in the full site editor, but in a way that is actually meaningful. It has been suggested that a user could simply set the revisions constant. However, particularly in an environment that encourages ""tinkering"" like the Gutenberg full site editor would be, it is entirely possible that a user could create a thousand revisions in a very short period of time. Since there is no way to know which revision is which / search revisions, allowing users to ""backspace"" isn't meaningful. Having ""branches"" would also allow plugin authors to create simple mechanisms to do A/B split testing on appearance (not content, that should still be possible). Moreover, this has a huge implication on the size of the mySQL database, particularly in shared hosting environments and particularly when site content is exported and imported using the core Tools. While it is not feasible to keep 35 trivial changes to the background colour, every semi-colon change to a Terms of Service may very well be crucial. The core infrastructure should allow (whether inside core or via plugin) for different treatment of different post types in regards to revisions. This ticket is related to https://core.trac.wordpress.org/ticket/21666, but is not a duplicate.",enhancement,new,normal,Awaiting Review,Revisions,5.4,major,,,,performance