Is CORE_SECURITY_PREVIOUS_MINOR the right version for "previous minor"

Slack thread with some comments that made me create this issue: https://drupal.slack.com/archives/C03L6441E1W/p1721851858152709

Possible workarounds for the above situation:

variables:
  CORE_SECURITY_PREVIOUS_MINOR: 10.2.7

or

composer (previous minor):
  variables:
    DRUPAL_CORE: 10.2.7

Though this will not make sense anymore if a new 10.2.X release is a security one.

Another slack thread: https://drupal.slack.com/archives/C1BMUQ9U6/p1752176458373939

TLDR; this one says that for the hook classes that were added to 11.1, the hook order classes didn't make it into the latest security release. that leads to a problem if you need to use them.

I really think that it's more confusing to have the security version rather than the latest stable previous minor.

I added the new variable, made the needed checks.

First test with wrong value (so the script detects it): https://git.drupalcode.org/project/gitlab_templates/-/jobs/5854307
Second test with the correct value: https://git.drupalcode.org/project/gitlab_templates/-/jobs/5854320

I am keeping all the logic for the other variable as we do it for a few other values, even if they are not used within the templates.

This is ready for review.

Looks good, left a couple of suggestions in the MR.

Do we need to consider BC here? If a custom template has set the old variable CORE_SECURITY_PREVIOUS_MINOR to something, expecting that to be used in 'prevoius minor'. Not sure how we do that, as the old variable still has a value within this new set-up. So we can't check for whether it has a value. There is a way to reference variables from other sections, so could we give a warning if CORE_SECURITY_PREVIOUS_MINOR has a value other than the value defined in hidden-variables.yml ?

Thanks for the suggestions, I've applied those.

I don't really think we need to do anything about BC in this case. We are changing the behaviour very slightly, for something that probably makes even more sense, and we are documenting it. One could even argue that using that value was a bug. It's similar to what we did here: 📌 Use stable core versions Active .

We can post a message in #slack or even create a change record, tho I don't think that the latter is needed.

Yes, that's OK with no BC. You are right that there isn't really any case to solve. No CR but a simple message in slack would be good. Also I have changed the issue title to be specific, and we can make sure the commit message and changelog are very clear (those are more important as they persist, whereas a message in Slack may only be seen by a few)

I have added the (unrelated) missing word to .gitignore as per the discussion on #3532272-13: ESLint needs to ignore /vendor folder →

I have also swapped round the display order of CORE_PREVIOUS_MINOR and CORE_SECURITY_PREVIOUS_MINOR so that the sequence is sort of getting older as the list goes down. Easier to understand 11.1.8 then 11.1.5 then 10.5.1. New output is

Current values of the variables             Variant where this is used
- CORE_STABLE:                  11.2.2      Current and max PHP
- CORE_SECURITY:                11.1.5      <unused>
- CORE_SUPPORTED:               11.2.x-dev  <unused>
- CORE_PREVIOUS_MINOR:          11.1.8      Previous Minor
- CORE_SECURITY_PREVIOUS_MINOR: 11.1.5      <unused>
- CORE_PREVIOUS_STABLE:         10.5.1      Previous Major
- CORE_MINOR:                   11.x-dev    <unused>
- CORE_NEXT_MINOR:              11.x-dev    Next Minor
- CORE_MAJOR_DEVELOPMENT:       <empty>     Next Major
- CORE_LEG_STABLE:              7.103       Drupal 7 tests