Explore setting up drupal/sector_recommended

Problem/Motivation

Since the early days, Sector has used exact version constraints for its dependencies. This was decided by the product owners as being a critical to the project so that each version build would be 100% repeatable and stable with Sector taking ownership of its dependencies being testable and functional.

However, this has been annoying for some developers and projects who have wanted to use different versions of core or modules, upgrade early, or simply be frustrated by Sector releases being delayed and falling behind on core/contrib releases.

The current Sector 10 dev branch already uses permissive carat versions, so what is needed is a tool and process to create constrained and tested releases of Sector when new release tags are made.

Past issue and discussion: #3225472: Prefer caret rather than exact version constraints in composer.json →

Proposed resolution

We are trying to ensure Sector follows established conventions and practices where possible. Drupal core has fixed this issue and we should follow its example by providing 2 options for users.

1. Permissive: drupal/core
2. Exact: <a href="https://github.com/drupal/core-recommended">drupal/core-recommended</a>

Require this project instead of the drupal/core subtree split in order to guarantee that all of the dependencies from drupal/core will be included in your Drupal site at exactly the same version that was tested with the version of Drupal you are currently using.

The consequences of not using this project is that Drupal's dependencies may "float up" to more recent versions than were tested with Drupal when you use Composer to upgrade your Drupal site. Occasionally, new dependency versions introduce bugs in Drupal. While these sorts of errors are usually corrected fairly quickly, it can still be quite disruptive to be one of the first people encountering one of these bugs. Using the recommended dependencies avoids this problem by only using dependency versions that have already been tested with Drupal.

We will provide the following packages via Drupal's Packagist:

1. drupal/sector (this project)
2. drupal/sector_recommended (name TBC / project page TBC)

Remaining tasks

• Investigate and test the package generator on Sector: https://github.com/webflo/package-generator-drupal
• Determine if a lock file will need to be committed against Sector to support this.
• Create the new general project for Sector Recommended.
• Plan out a new release process for recommended releases.
• Automate and script this process so it happens when new tags are made against drupal/sector.

Project user changes

Every project using Sector will need to change the following in its composer.json requires section:

Replace sparksinteractive/sector-distribution with either drupal/sector_recommended for a safe and tested product with regular releases to drupal/sector for an unlocked version using permissive carat constraints.