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

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.

This is the main blocker here.

Regardless of what we do, we need to have some kind of magic value for "the initial schema of a module that's installed when it doesn't already have any update hooks" - at the moment that is 8000, it could be 1000, or -1, or NULL. It's stored in the key_value table serialized, so it can be any arbitrary thing. Once we lower it, we can't raise it again.

We can rename the constant to something like DEFAULT_INITIAL_SCHEMA_VERSION with a deprecation of the old one, but can't remove the concept.

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, are 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 📌 Decide what to do with Drupal::CORE_MINIMUM_SCHEMA_VERSION and surrounding logic Active 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 9000 for that case, because 90 is used in some software version numbering as alpha (eg in KDE releases).