Planning for CRAP and entity revisions everywhere in core

At DrupalCon Barcelona this year I presented with Dick Olsson outlining a plan for CRAP (Create Read Archive Purge) and revisions (on all content entities) in core.

Phase 0

For Drupal 8.0.0
Enable revisions by default (https://www.drupal.org/node/2490136) on content types in the standard install profile and when creating new content types.

Phase 1

For Drupal 8.1.0

• Improve the Revisions API performance, some of this will come from moving elements from the multiversion module into the entity API.
  
• Enable revisions by default for all content entity types. So not just nodes anymore but blocks, comments, taxonomy terms etc.
• Introduce a revision hash, parents and tree. Each revision needs to have a parent so you know where it’s come from, each parent can have multiple child revisions.
• Data migration - Moving all 8.0.0 sites to 8.1.0 will mean moving their data to the new revision system.

Phase 2

For Drupal 8.2.0

• Remove the ability to not have revisions. To simplify the API and the data stored it makes sense to remove the ability to disable revisions. This will allow us to remove all the conditional code around if an entity has a revision or not.
  
• Delete is a new flagged revision. When deleting an entity a new revision will be created and this revision will be flagged as deleted. This is the archive element of the CRAP workflow.
• Introduce purge functionality. There may be times when an entity needs to be completely deleted.
• Commit trash module to core. Trash is just a UI for the delete flag. It displays all entities marked as deleted. It then allows these to be restored by creating a new revision not flagged deleted, or purged by removing the entity.

Simple right?