Problem

Configuration schema and data are both versionless. There is nothing to tell if a given yml file is for a given version of a module. Modules however will likely change their configuration structure, such as contrib views plugins would change how they store settings or panels could change how it stores a panel config entity in any release.

The stance so far of the config system on this is "it is up to the module to update the data proper". As with update functions for other things, when you update a module, the update functions would need to take care of updating the config structure from old to new. That in itself is fine.

With the configuration override and schema system however, configuration overrides from the core locale module, from the contrib config_translation module, from the contrib organic groups, from the contrib domain module, etc. might also exist on the system. These contain overrides in the structure of the original config, so when merged they serve as configuration applicable to specific use cases (for languages, domains, groups, etc).

1. When such an update happens, all the modules dealing with configuration overrides need to react to the schema change too. They need to update the structure of the override files, so that they properly map to the new structure. If an override file in an old structure if applied to the new structure, it could lead to negative consequences of different proportions. Therefore when such updates are done, said core and contrib modules would need to have access to the old data and the old schema and the new schema and new data so they can regenerate the overrides in the proper new structure at least to their best effort.

2. Another related problem is how localize.drupal.org works to parse translatable strings from data yml files. When a project is encountered, the parser can look for all the required modules to load their schemas, so any data that is based on required modules can be inspected. Such as a "feature module" that is a couple views and panels and depends on views and panels would need the base schema of views and panels so we can parse their data. Most .info files would not specify concrete version numbers for dependencies (for obvious and good reasons), so localize.drupal.org needs to guess most of the time for the schema version to use. If the module required for the given project has multiple schema variations through its life, the backend will need to pick a version.

Proposal

Discuss!

Comments

Problem (1) and (2) may or may not be the same depending on how we want to approach solving them.

For (1) we can enhance the core runtime system with copying the schema files to active storage too for example, so we can diff old and new schemas (old being in the active store, new being with the updated project in the source code) and use the old vs. new data as well. Core would also need to provide API functions that people would need to invoke when data is updated so the modules providing overrides can react and get the old/new data/schema.

However in (2) there is no runtime knowledge of old and new, there is just one version of data and then multiple versions of schemas. Possible solutions include versioning the schemas and the data, so for example put in a "version: 1.0" key to the data where external types are involved to refer to the version of the type and document in the schema which version of the schema it is. Another possibly uglier option is to include the version number in the type name, so it would be image.plugin.type.v2 or something along those lines. So when referring to a type, the schema would explicitly say which version of the data type is being referred to.

Any great ideas?

There's an existing issue about versioning/module compatibility - I've looked for it twice since yesterday but can't find it..

Right, I'd love to cross-reference but keep this its own issue, since this has far reaching consequences for both updates AND localize.drupal.org, later which does not have to do anything with updates and a solution is needed for much earlier than release, so we can offer up Drupal 8 stuff for translation there proper to be ready for release.

http://drupal.org/node/1427826 contains instructions for updating the issue summary with the summary template.

The summary may need to be updated with information from comments.