Opening this to discuss and track the progress towards providing a beta-to-beta upgrade path.
So far this is the only defined intermediate step between beta and RC.
I've slowly been tagging issues that either fix the upgrade path or would require an upgrade path with the D8 upgrade path tag.
Some issues block providing an upgrade path, some will require extra work once we support an upgrade path, some won't be allowed during beta once we provide an upgrade path.
Initial draft on the criteria for announcing support, and what happens to issues afterwards:
Must block a supported upgrade path between betas
- Critical issues in the upgrade path infrastructure itself - because it needs to actually run properly.
- Critical data integrity issues - because we need a starting point of data that is not broken before we try to update that data.
(There are not really 'major' versions of the above - those issues should be marked critical)
Should block a supported upgrade path between betas
- Critical issues that require an upgrade path to be written - to avoid having to write and support data migrations for critical issues we already know about.
- Critical issues that require additional steps to be taken after updating code (other than running update.php), this means issues with changes to the following:
- Container rebuild.
- Editing .htaccess / web.config
- Editing: settings.php / services.yml
- Forward ports of 7.x security issue in the public issue queue: https://www.drupal.org/project/issues/search/drupal?project_issue_follow...
- Major bugs that require an upgrade path to be written - if we find ourselves with 20 RTBC major bug fixes on the day a beta is supposed to be released that will all need re-rolling with data migrations, then better to commit them before than after. However no specific major issue should block - if it's that important it can be bumped to critical.
- Updating third-party code to the latest versions, e.g. and
Changes once the upgrade path is supported
Once the upgrade path is supported, several changes happen:
- Any issue that requires a hook_update_N() will be required to provide one once the upgrade path is supported.
- Any issue that requires a service container rebuild, .htaccess, web.config, settings.php or services.yml update will require a change notice + mention in the release notes, or potentially not be allowed if it's a minor change that would cause instability for existing installs.
- Normal or major issues that require a non-trivial hook_update_N() may get moved to 8.1.x (or 9.x if the change isn't doable in a minor version at all) once the beta-to-beta upgrade path is supported, to avoid pushing out the initial release in case they introduce bugs. This will have to be decided case by case.
- Additionally, any normal issue (and most major tasks) that require a hook_update_N() should be marked 'minor version target' - we'll want to minimise the number of updates that need running for 8.0.1 etc.
Open issues tagged 'D8 upgrade path':
|#52||Updating___Drupal_8_-_Update_-_EN 2.png||83.47 KB||plach|