Based on a slack discussion with @amateescu and @plach:

Problem/Motivation

From: https://www.drupal.org/project/drupal/issues/3023194

As mentioned above, each revision has contextual metadata attached, allowing to look up the fittest revision for the specified context. In fact, a revision matching exactly the specified context might not exist, so a fallback logic needs to be available. The context hierarchy defined through weights is used to support that: more and more generic fallback contexts are built until a suitable revision is found. For instance, the following situation may happen:

 Current context:  [ws: stage, lang: it, user: 4]
 Fittest revision: [ws: stage, lang: it]

To be able to select the "active" or "fittest" revision for the current context, the revision has to store the related context values in an accessible and queryable manner.

Proposed resolution

A solution proposed by @amateescu: Revision negotiation relies on entity or revision fields. Every context provider defines the field name that is used to determine a revisions "fitness" :D

For example:

 Current context:  [ws: stage, lang: it, user: 4]
 Fittest revision: [ws: stage, lang: it]

The language context would use the existing langcode field. The user context the revision_id field and the workspace context would rely on a workspace field (follow up ticket). This would result in SQL conditions that can be used to order revisions:

select revision_id, (langcode = 'en') * 2 + (revision_uid = '1') * 1 + (workspace != 'stage') * -1 as fitness from node_revision where nid = 1 order by fitness desc ;

This example would prioritize revisions in the current language and then by the current user but deprioritize any revision that is not in the current workspace.

Remaining tasks

  1. Add an extension point for context providers to define entity field names.
  2. Provide a configuration schema and page for managing context and weights.
  3. Extend the `getActive` implementation in https://www.drupal.org/project/drupal/issues/2942907#comment-12910929 to take context fitness into account.
  4. Refactor the workspaces module to use a field instead of the workspace_associations entity. (follow up issue)
  5. Provide an upgrade path for the workspace module. (follow up issue)

Comments

pmelab created an issue. See original summary.

pmelab’s picture

pmelab commented

Version: 8.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 11.x-dev » main

Drupal core is now using the main branch as the primary development branch. New developments and disruptive changes should now be targeted to the main branch.

Read more in the announcement.