Provide D7 -> D8 Views upgrade path in contrib, not core

Yummy! Less the upgrade code, less to worry about...

+++ b/core/modules/views/views.install
@@ -28,51 +28,43 @@ function views_schema() {
-function views_update_last_removed() {
...
+function views_update_last_removed() {

Can we move this back up? — usually comes after hook_schema(), but before individual update functions.

+++ b/core/modules/views/views.install
@@ -28,51 +28,43 @@ function views_schema() {
+function views_schema_8000() {
...
 function views_update_8000() {
...
+  $schema = views_schema_8000();
+  _drupal_schema_initialize($schema, 'views', FALSE);
...
+  foreach ($schema as $name => $table) {
+    if (!db_table_exists($name)) {
+      db_create_table($name, $table);
+    };
+  }

update_module_enable() implements a hook_schema_0() facility for basically the same... although it lacks the db_table_exists() condition. Perhaps it would make sense to inject that logic through an optional flag into update_module_enable()?

That plan sounds more reasonable to me.

We also did not provide any kind of upgrade path for all the field type modules that we've added to core for D8 — even though there are direct clashes with the field type names (and supplying an upgrade path for that in contrib will be quite a pain).

But yeah, that would at least be consistent, so +1 for removing this altogether.

+++ b/core/modules/views/views.install
@@ -35,44 +35,40 @@ function views_update_last_removed() {
+ * Set the Views schema version.
  */
 function views_update_8000() {
...
+  // No update, just set the schema version to 8000.
 }

That looks like the exact job of hook_update_last_removed() to me ;)

So we should just swap out the schema version, I think.

I'm not sure whether it makes sense to specify any removed version number though. As soon as the D7 contrib Views module will see a new module update, the logic will no longer work.

+++ b/core/modules/views/views.install
@@ -35,44 +35,40 @@ function views_update_last_removed() {
+  // Display a warning if the user attempts to update with a Drupal 7 version
+  // of Views. An upgrade path is provided by the views_d8_upgrade contributed
+  // module, which uninstalls Views before beginning the Drupal 8 upgrade.
...
+          'Your installed version of Views is too old. To migrade Views data from Drupal 7, install and run the <a href="@url">Views Drupal 7 to Drupal 8 upgrade</a> module before installing Drupal 8.',

Hm. I'd prefer to leave this out entirely. As said, we did not introduce any special care for the new field type modules in D8, and we also did not do so for the entire CCK thing in D7.

--

All things combined, I think we should remove the hook_update_last_removed(), existing schema updates, and also don't introduce any hook_requirements(). All of this can be handled by the contrib migration module.

Nice diffstat ;)
After all of the conversation around this, I think this makes the most sense.

Well then. :) Less code FTW, I guess. :)

At some point tonight I must've committed this because patch -p1 asks me if I meant -R. Woot. ;) Thanks!

Btw, is there any particular reason for why you plan to use a separate project instead of the views project directly for the D8 migration module?

Normally and technically, project != module. AFAIK, all tools that we have are able to properly differentiate between the two notions. IIRC, the CCK project was also continued for D7, but contained a content_upgrade.module or similar instead of the former module(s).

Not if we emptied out the 8.x branch to only have the upgrade path module...

There we go!

Committed and pushed to 8.x. Thanks!