We're running out of hook_update_N() numbers

This is a really interesting problem!

I was thinking for a second about splitting up the version numbers: system_update_8_6_20. Looking at \drupal_get_schema_versions and \update_get_update_function_list it seems to be possible to allow both kind of number schemes, while keeping a custom sort function around.

Since the hook_update_N() system is very old and we want to switch more and more to events: How about introducing an event for updates? The event listener would have a version, which would be applied into the database. That way we could mark hook_update_N() as deprecated.

I haven't looked at the code, but isn't the simplest thing to do what the Issue Summary suggests for 8.10.x (go to 5-digit schema versions), but then to keep 5 digits for Drupal 9, numbering 9.1.x updates from 90100, and so on?

Yeah, what #9 said. the update system only cares about one thing.. storing the last-updated number and then running all updates with a bigger number. We could have a number like 81456444, the update system couldn't care less, as long as the 9.x updates will use the same amount of digits/be an even bigger number.

I think this is basically non-issue, worst case is we have to update some documentation if we actually have to do this :)

Let's see whether this test passes.

@xjm: Only in case 10k update functions wouldn't be enough for 9.x :) But I see you already edited your comment, still got the see the old one thanks to e-mail notifications ;)

That was certainly an "interesting" use of the state API @dawehner :)

Rerolled, removed the unrelated part so it applies and also added a second part that makes sure additional update functions are executed/not executed as expected.

Since this just adds test coverage for something that works fine, I don't think it needs to be critical. As mentioned above, beside the test coverage, the only thing we probably need is adjusted documentation once/if we reach 8.10 but that too doesn't seem critical.

Yeah I call it poormans-backtrace.

+++ b/core/tests/Drupal/FunctionalTests/Update/UpdatePathTestBaseTest.php
@@ -94,4 +94,31 @@ public function testUpdateHookN() {
+    // Ensure that 810002 was executed but 8302 was not since we were already
+    // past that number.
+    $this->assertEquals(['update_test_schema_update_8002', 'update_test_schema_update_8301', 'update_test_schema_update_810001', 'update_test_schema_update_810002'], \Drupal::state()->get('update_test_schema_high_schema'));

Nice additional test coverage. I also like these kind of explanation comments!

I agree its not critical, given we figured out it actually works.

@xjm: I'm not sure. For now, nothing changes. If we never reach 8.10, nothing will change, not for 8.x.

It seems rather abstract to document that theoretical possibilty now if it wil not actually happen. For example, we can't document that 9.x update numbers must start with 90001 because there is no reason to do that now if we don't get to 8.10. And I also don't think we should switch *now* to 80601.

We could postpone this issue and dig it out again when we actually get there? Or have a follow-up?

@xjm
Documenting this sounds like a good idea. What about a documentation like this

I think having test coverage now is still useful, otherwise we don't detect it, in case we introduce this problem due to some other changes ...

I thought about just adding that. But if we do that, then we also need to document that if you *ever* do that, you will need to stick to 2 digits then for the minor version also for the future. And at least for core, once get to 8.10, we will want to switch every module to two minor digits for 9.x even if they didn't have any high update functions in 8.x.

Good point.

You would need to do that within a given file, right? Could we validate that somehow and throw a warning in case someone has N and N-1 digit update functions?

Hm. Having 8901 and 81001 is perfectly fine. Just 81001 and then 9001 wouldn't make sense*. So we'd need to verify that the first digit is larger but it has fewer digits?

Not sure, you will find out quickly if your update function isn't being executed?

* this is an interesting example though. Lets say we go until 8.9 and then the next release is 9.0. That means we need to be aware that we can *not* ever add a 8.10 for whatever reason and expect to be able to add 81001 update functions. But even for that, there's a fairly simple workaround. We can just start at 8950 or so. After all, it is just a number, we'd just violate a bit our semantics. Afaik our current release schedule doesn't plan on having that situation and we could still decide that we will switch to 5 digits in 9.x even if we don't reach 8.10, just to be on the safe side?