Work is underway on a Drupal 8 version or equivalent of the Features module.
Given that Configuration Packager covers some of the territory of Drupal 7 Features, there are various scenarios:
- The two are independent projects.
- Features depends on and enhances Configuration Packager. Possibly, Features provides a front end UI for Configuration Packager.
- Features is replaced by Configuration Packager, and work towards a D8 Features takes place in Configuration Packager.
- Configuration Packager is merged into a Drupal 8 branch of Features and further work takes place there.
The first of these would be a bunch of duplication, so let's avoid it. The others are all worth considering.
As part of this discussion, here are design principles for Configuration Packager; see the project documentation. For familiarity, this list uses Features vocabulary. Before merging, we should agree on a set of principles that will guide all subsequent work.
- Interoperability baked in. Interoperability between different features and feature sets is not an add-on or option but a core principle reflected in the basic design of the project. The default settings of Configuration Packager should facilitate creating and maintaining interoperable configuration modules and distributions. See the page on interoperability features.
- The site/feature set as a whole. The primary unit of interest is the site as a whole as it maps to a feature set. Creating and editing individual features is also of interest, but is a derivative problem.
- Work with core. Wherever possible, we should work with Drupal core. This includes working directly with core's configuration management API. Overriding default core patterns should be reserved for scenarios where doing so satisfies a critical requirement and is absolutely unavoidable. For example, the installation of configuration from features-type modules should work out of the box with core's default configuration installer without any non-core dependencies.
- Packaging problem only; best shared solutions. Effort and functionality should focus narrowly on the problem of "packaging a collection of Drupal entities which taken together satisfy a certain use-case". Wherever feasible, solutions should be moved out of the project into more generic solutions that address configuration management needs beyond those specific to the packaging problem. This solution or solutions should be added as dependencies. Where functionality is added that is potentially generic, it should be done on an interim basis with the longer term aim of moving it to a generic solution.
- Comprehensive test coverage. Despite its current state (testless!), code should include comprehensive test coverage. Primary reliance should be on unit tests, with Simpletest-type tests used only when a unit test is not feasible.
- Core-worthy quality. All proposed changes to the code base should be assessed on the criterion: is this code worthy of Drupal core in terms of quality and elegance? In particular, rather than introducing dubious workarounds with the hope of later refining, it's preferable to leave a feature out.
- A drupal.org issue for every change. All changes, even relatively trivial ones, should be done through the issue queue.
- Maintained on drupal.org. The project should be maintained on drupal.org rather than some external site (e.g., GitHub).
- Developer-only toolset. The focus should exclusively be on the use case of developing features extensions and should not introduce a dependency. That is, the module should never be required on any client site in order for the functionality it packages to be available.
Depends on the solution selected.
If it's to merge into Features:
- Create a new branch of Features and create an (initially, empty) dev release, so that the issue system will include that branch.
- Move all tickets (including closed ones) from Configuration Packager to Features, ensuring they're tagged to the correct release.
- Move all Configuration Packager documentation pages to a new section of the Features documentation book section, updating as appropriate (e.g., "Configuration Packager" to "Features", "package" to "feature").
- Assign nedjo commit access to Features.
- In the Features repository, check in all current code from Configuration Packager as is. (TBD: is it possible to carry forward the git history?)
- Rename all files and their included code to use the Features namespace and also to adjust code comments and strings as appropriate (e.g., package to feature).
- Update the Configuration Packager project page, pointing to the new home.