Note: This is issue is part of #2721129: Workflow Initiative and is only meant for planning and governance sign-offs. Work will happen in child issues of this plan.

The idea of this phase it to implement and use our great revision API for all content entities in core, except users. This will provide a necessary foundation for any moderation, workflow and staging capability. No new features or functionality is being added to the Entity API in this phase.

The issues below needs to happen somewhat sequentially:

  1. #2490136: Enable revisions by default
  2. #2707255: All content entities should inherit baseFieldDefinitions
  3. #2705433: Node should implement RevisionLogInterface
  4. #2716081: BlockContent should have revision_user and revision_created fields and implement RevisionLogInterface
  5. #2721313: Upgrade path between revisionable / non-revisionable entities
  6. #2745619: [policy, no patch] Which core entities get revisions?
  7. #2705389: Selected content entities should extend EditorialContentEntityBase or RevisionableContentEntityBase

These additional issues should happen by the end of phase A:

Must

Should

Could

These issues will not be blockers, but could be good issues for sprints or contributors wishing to assist with the initiative.

Sign-offs needed

Product manager

A product manager needs to sign-off on this plan because the revisioning user experience is not as polished as the non-revisioned user experience, so the planned work significantly affects the out-of-the-box experience of the product.

Framework manager

A framework manager needs to sign-off on this plan as the above phases introduces a small, but very significant, API addition (parent revisions).

Release manager

A release manager needs to sign off because the scope and impact of the work are significant for core, and because existing issues with revisions may impact the stability and technical debt of the developmental minor version.

Sub-system maintainers

The sub-system maintainers for the Entity API needs to sign-off on this plan as it significantly impacts the Entity API.

Sign-offs given

  • Product manager - Pending completion of the issues listed above
  • Framework manager - Pending specific implementation in phase A; not yet given for phase B
  • Release manager - Pending completion of the issues listed above
  • Sub-system maintainers - pending

Comments

dixon_ created an issue. See original summary.

dixon_’s picture

Issue summary: View changes
Issue tags: +Needs framework manager review
dixon_’s picture

Issue summary: View changes
dixon_’s picture

Issue summary: View changes
dixon_’s picture

dixon_’s picture

Issue summary: View changes
dixon_’s picture

Issue summary: View changes
dixon_’s picture

Issue summary: View changes
xjm’s picture

Issue summary: View changes
Issue tags: +Needs release manager review

Added an item to the summary for release manager signoff, because this has an impact on the technical debt and releasability of 8.2.x. For example, there are a number of existing bugs and limitations with revisions that become more problematic when we use revisions in more places. I'd like to see an overview of those bugs here, and consider what we need to fix in order to consider the work on revisioning releasable.

For some of my concerns, see #2490136-101: Enable revisions by default. For example, #1239558: Deleting an entity with revisions and file/image field does not release file usage of non-default revisions, causing files to linger could be a scalability problem already with just nodes being revisionable by default. Some of the issues we added on the main roadmap #2721129: Workflow Initiative under "Related work" might also belong here.

xjm’s picture

Issue summary: View changes

Also clarified why product manager signoff is important and added that for release managers too.

catch’s picture

dixon_’s picture

Status: Active » Needs work

Thanks @xjm and @catch for your additions here. I will look through these issues and add them in to the plan soon.

catch’s picture

catch’s picture

amateescu’s picture

catch’s picture

I think we should split the revision hash/parenting issue out to a separate issue, since they only block phase H.

And/or if they block something earlier could that be clarified?

xjm’s picture

catch’s picture

catch’s picture

catch’s picture

catch’s picture

catch’s picture

xjm’s picture

Here's an update on the status of this plan from the committers!

Release manager
A release manager needs to sign off because the scope and impact of the work are significant for core, and because existing issues with revisions may impact the stability and technical debt of the developmental minor version.

To address this, the framework managers, release managers, and Entity Field API maintainers did a triage of revisioning issues with the Workflow team last week, with these results:
https://docs.google.com/spreadsheets/d/14lpbLhpu7YqjFwjQ4gCTTlf-gcrOc57C...

For each issue, we identified which must, should, could, and won't block or be a part of this phase of the initiative. We can update the summary here for that info, but this has release management signoff based on the planned scope of work and those related issues being included.

Previously @catch and I had concerns about the impact of enabling revisioning for many entity types in core without a way to manage the revisions, but this phase is not about that. It is simply about providing the API and storage. The revisioning flag will not be set for core entity types other than nodes during this phase, nor possible to enable through the UI.

Product manager
A product manager needs to sign-off on this plan because the revisioning user experience is not as polished as the non-revisioned user experience, so the planned work significantly affects the out-of-the-box experience of the product.

These were the things that needed product manager signoff for this phase:

  1. User experience changes out of the box as a result of #2490136: Enable revisions by default -- most issues were already addressed in the original issue, or are covered by the "must" revisioning work in the spreadsheet above. One outstanding issue affecting the product usability was #1776796: Provide a better UX for creating, editing & managing draft revisions., and @webchick commented there agreeing that one can be a "should" or even "could" for this phase.
  2. Proposed revisioning UIs for other entity types -- no longer in scope.

Based on that, @webchick said it was okay to remove the "Needs product manager review" tag here as well.

Finally:

Framework manager
A framework manager needs to sign-off on this plan as the above phases introduces a small, but very significant, API addition (parent revisions).

The framework managers were comfortable with phase A overall, pending reviewing the implementations of the remaining steps of course. However, they were less sure about phase B. Based on that, we thought it might be worthwhile to split Phase B into a separate issue.

xjm’s picture

Issue summary: View changes

Adding the other must, should, and could revisioning issues to the summary.

xjm’s picture

xjm’s picture

Issue summary: View changes

Clarifying WRT the signoffs in the summary.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.0-beta1 was released on August 3, 2016, which means new developments and disruptive changes should now be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

dixon_’s picture

Title: WI: Use and extend the revision API » WI: Phase A: Use the revision API in more places
Issue summary: View changes

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

catch’s picture