Decide what to do with Drupal::CORE_MINIMUM_SCHEMA_VERSION and surrounding logic

> I suppose it doesn't hurt to leave it as it is, but I feel like we could also just remove that and let contrib and custom modules in the future use lower numbers.

That would be nice in theory, especially as we'll eventually remove the 8.x- prefix and modules will just have a release like 1.2.0, so it feels natural to have a 1200 or whatever update.

But, we did discuss that before, and thinking about it again, I think there's a problem with removing this check. Only a module that would require a core version where this is removed would be allowed to add a lower update, and it must be a *completely new* module that has never been installed before. A module that was installed at one point on a site would have been initialized at 8000 and adding a lower update wouldn't be executed.

To avoid that, Drupal core would need an update function that would set each schema version that is currently 8000 to 0 or 1000 or whatever we decide is the new minimum/special number.

Is there any downside in simply leaving it alone for now? Aside from just have an extra codepath or whatever.

While we decide what to do with this, calling attention to #3010334: Document how contrib hook_update_N() should be numbered now that modules can be compatible with multiple major branches and versioned semantically which seems like a potentially huge complicated can of worms for the semver-only future. It'd be great to get some clarity there on how the whole update_N() system will work in the semver world, so we don't add or remove things from core that we might wish we picked otherwise. ;)

Thanks,
-Derek

It kind of hard to discuss this and #3010334: Document how contrib hook_update_N() should be numbered now that modules can be compatible with multiple major branches and versioned semantically separately now. Because they are so connected.

Once we have semantic versioning for contrib projects if we don't change Drupal::CORE_MINIMUM_SCHEMA_VERSION value or logic what would be recommend for 1.2.0? my_module_update_1200 won't run correct? my_module_update_8001 would run but that seems really weird for a new module which may or may not ever be installed on Drupal 8(maybe core 9.3.0 is current).

We if we recommend new modules to start there update hooks >10000. This would run and would could separate a modules hook_update_n implementations from core's major version which I don't think should be connected anymore with modules being able to be compatible with multiple core versions.

> my_module_update_1200 won't run correct?

Correct.

But you also have to keep in mind a module that currently has a 8.x-1.x release with some 800x updates and now does a 2.x.y semver release, based on the screenshot in slack I understood that this is how it will work. That module can't suddenly add 200x updates as that is lower than its existing 800x updates and drupal wouldn't run them. So one solution would be to add a digit, as you suggested:

> We if we recommend new modules to start there update hooks >10000. This would run and would could separate a modules hook_update_n implementations from core's major version which I don't think should be connected anymore with modules being able to be compatible with multiple core versions.

But there some challenges with that too:

* We can't just increase the constant, that would invalidate all existing updates that modules have and are still allowed to add
* I don't think we should have different rules for core and contrib/custom modules. They're all just modules, even if we could it would require some hacks, and since modules can move out and in of core, that makes it even tricker.

So if we recommend 5 digits from now on, then a module that has a 2.0.0 release with some updates moves into core which still uses MAJOR(MINOR)xx (so 9000 and with D10 10000) we are in trouble.

From my quick looks into how doctrine works, I think their "versions" are numbers but basically they're just dates, does anyone know how you deal with major releases then?

I think it's too late to increase \Drupal::CORE_MIMIMUM_SCHEMA_VERSION for Drupal 9; we're stuck with 8000. But then, we're also stuck with \Drupal::CORE_COMPATIBILITY of 8.x as well. We should address both during the D9 cycle.

I documented best practices for hook_update_N() ordering in #3010334: Document how contrib hook_update_N() should be numbered now that modules can be compatible with multiple major branches and versioned semantically for the meanwhile.

CORE_MIMIMUM_SCHEMA_VERSION needs to be removed.
Module must set their schema version at install.

I'm having a similar issue with the Statistics deprecation : currently, the core version includes a statistics_update_10100() already, but the contrib version starts with release 1.0.0, and I do not see how to make this work. Maybe access the schema releases info in hook_install, and erase the previous core-related recorded updates to enable the 100x series updates to run.

That seems fairly acrobatic.

Gave feedback in slack too. You need at least 10000 anyway right now if you want to to match your version number as the minimum is 8000. The only difference is that extra 100 you have in there, and if you really don't want that, you can add another 0 to make it 100000.

100x update numbers are not supported.

Update version number don't care about core/contrib, semver or not. It' just a number and any new number needs to be larger than the previous one and it needs to be larger than 8000 until this issue is resolved.

I agree that it would be useful to rename and lower the constant from the historic 8000 to anything else, but it's not as trivial as it sounds (any existing installed module has 8000, so we'd need an update function to lower that) and it will not happen in time for you.

In the #3106712: Decide what to do with Drupal::CORE_MINIMUM_SCHEMA_VERSION and surrounding logic I'm trying to describe the general standard for numbering hook_update_N related to semantic versioning, and starting new numbering from 10000 fits well into the approach (for the release 1.0.0).

The problem is only with the pre-stable release numbers like 0.1.0, but this is not very popular case, so let's stick to 8001+ for that case, because .80 is used in some software version numbering as alpha, .90 as beta (eg in KDE releases like 5.80.0 - 6.0-alpha1, 5.90.0 - 6.0.0-beta1, 5.95.0 - 6.0.0-beta2, 6.0.0 - 6.0.0 release).