Support multiple minor branches on two major branches

I'm a bit confused by this.

If we have 11.0.0 (no alpha, beta or rc, stable version) that’d become the current minor in that case. and any 10.2/3/4… would become previous major, won’t it? Up until 11.0.0, any 11.x would still be considered next major.

Also, for security, once 11.0, I guess that’ll be the recommended security release instead of 10.2 right?

Yes 11.x would be the current major, 10.x would be the previous major, 12.x wouldn't exist yet but eventually will, with some 10.x overlap (at least before it releases).

Also, for security, once 11.0, I guess that’ll be the recommended security release instead of 10.2 right?

Assuming a July/August 11.0 release, 11.0 and 10.3 will both be the recommended security release at that point (with 10.2 on security support only). If 11.0 releases in December, it would be 11.0 and 10.4.

Like fjgarlin, I was also confused by the request. I'm not saying that there is no problem, I just need some help to understand what it is. When we get 11.0, using the OPT_IN variable names to assist my thinking, we will provide contrib testing for the following:

OPT_IN_TEST_CURRENT = 11.0
OPT_IN_TEST_NEXT_MINOR = 11.1.x
OPT_IN_TEST_NEXT_MAJOR = 12.x (when it exists)
OPT_IN_TEST_PREVIOUS_MINOR = 11.0 (when CURRENT has moved on to 11.1)
OPT_IN_TEST_PREVIOUS_MAJOR = 10.3

Are you saying that we need to provide testing at more D10 versions, other than the one specified in previous_major?

Are you saying that we need to provide testing at more D10 versions, other than the one specified in previous_major?

Yes exactly. Once 10.3.0 is released, we'll have the same 10.2 previous, 10.3 current, 10.4 next minor branch situation we currently do on 10.x, just with extra 11.x branches on top.

The original reason this came up in slack, is because we changed a test trait class name in 10.2, with a deprecation for removal in 11.x

This means it's possible to write tests using the new trait name in 10.2, 10.3 and 11.0, but it's not (easily) possible for those tests to pass on 10.1

So, if we were to be at 11.1.x (and 10.4.x), we'd have:

- Current: 11.1.x
- Next minor: 11.2.x
- Prev minor: 11.0.x
- Next major: 12.x (or main)
- Previous major: 10.4.x

Why would we need 10.3.x or 10.2.x or 10.1.x? I'm trying to understand whether this is a short term/transition need or a long term one.

Note that modules currently can tweak variants by tweaking variable values (ie: CORE_NEXT_MINOR) or they can also easily create new variants with some code like this:

composer (custom variant):
  extends: .composer-base
  variables:
    PHP_VERSION: 8.3
    DRUPAL_CORE: 10.2.x
    IGNORE_PROJECT_DRUPAL_CORE_VERSION: 1

phpunit (custom variant):
  allow_failure: true
  extends: phpunit
  needs:
    - "composer (custom variant)"
  variables:
    PHP_VERSION: 8.3

Why would we need 10.3.x or 10.2.x

10.4 adds a new API (or just constructor/render api change) backported from 11.1

This breaks tests on a contrib module, so it updates to fix it, but now because it's using the new API just added unconditionally, it breaks compatibility with 10.3 and 10.2 - and will only find out if tests run against those versions.

So, current variants (6 in total):
- CURRENT
- CURRENT_MAX_PHP
- NEXT_MINOR
- PREV_MINOR
- NEXT_MAJOR
- PREV_MAJOR

Suggested? (8 in total):
- CURRENT
- CURRENT_MAX_PHP
- NEXT_MINOR
- PREV_MINOR
- NEXT_MAJOR
- PREV_MAJOR
- PREV_MAJOR_NEXT_MINOR
- PREV_MAJOR_PREV_MINOR

Are the above correct? I wonder whether adding these new ones would only confuse people more. All of these need a deep understanding of the differences between minors/majors, which not all contrib maintainers would have.

We could document how to "easily" add variants (snippet in #6) so people can add them according to their needs. It's not even 15 lines of code that anybody wanting to add variants could easily copy/paste and extend from.

Maybe PREV_MAJOR_LTS is enough as new variant?

Adding link for context (which I was missing): https://www.drupal.org/blog/drupal-10-will-be-supported-until-the-releas... →

Following the release of Drupal 11.0.0 in 2024, a long-term support phase for Drupal 10 begin

If we have to add one (or two) new OPT_IN variables we need to avoid having both 'PREV' and 'NEXT' in the variable name :-) It's confusing enough, and that would just tip people over the edge. PREV_MAJOR_LTS is a big improvement, and it seems we only need to go back a version, we don't need PREV_MAJOR_NEXT_MINOR

I had previously done some investigation on which of the CORE_ version variables are actually used anywhere in this project (apart from in check-versions.php). So while we are discussing the variables, I thought it was sort-of relevant to include this here, as it may inflect the decisions.

Variables used

Variables not used

(values accurate as at 4 May 2024)

@catch - would adding CORE_PREV_MAJOR_LTS solve the issue? Would we still need another variant in addition to that one, or will that be enough?

I think that the LTS version is the think that makes most sense here.

I'm going to put together a quick POC that will need additional work but can be useful as a starting point.

POC merge request in place now: https://git.drupalcode.org/project/gitlab_templates/-/merge_requests/209
Pipeline: https://git.drupalcode.org/project/gitlab_templates/-/pipelines/177039

Needs accompanying documentation changes.

OPT_IN_TEST_CURRENT_LTS and OPT_IN_TEST_PREVIOUS_LTS are available.

It'd be great to have a first review to see if this would satisfy the needs of the LTS plan for Drupal. In that case, we can continue working on this and document everything accordingly.

Rename variables to follow #3447071: Review and try to simplify SKIP and OPT_IN variables → .

Needs accompanying documentation changes.

RUN_VARIANT_CURRENT_LTS and RUN_VARIANT_PREVIOUS_LTS are available.

It'd be great to have a first review to see if this would satisfy the needs of the LTS plan for Drupal. In that case, we can continue working on this and document everything accordingly.

Not sure about current LTS here, we don't really have a concept of that as such and it seems like it could end up a duplicate of CORE_STABLE?

Oh cool. When I was working on it I wasn't sure if there would be such a thing. I can remove all the curre_lts logic.

Although, in that sense, why would the "previous LTSæ (or just LTS) be different from "previous major" (which is set to CORE_PREVIOUS_STABLE)??

Re-read this again (after some slack discussion about contrib enabling all possible variants a lot), and I agree PREV_MAJOR_LTS will be enough for the vast majority of changes. We mostly need to know whether modules will continue to work with the oldest currently supported version of core, which will be whatever the oldest security-supported version of Drupal 10 will be.

It won't allow modules to test against what is currently 10.4 (i.e. the next minor release coming up on the old major branch), but that should only contain backported changes from 11.1, so it would be an extreme edge case for a module to work with 11.1, 11.0, 10.3, 10.2 but not 10.4 and we can worry about that if it starts happening.

I suggest we create a variable OPT_IN_TEST_SUPPORTED which causes tests to be run on all versions of core that are not EOL and that match the module's core_version_requirement.

I replied in the related issue why I think that doing that is not a good idea, at least for the default templates.

We currently offer 5 variants, all accessible by just altering one variable, and these variants cover a wide range of Drupal versions. This issue, about LTS, is a very specific case, and even this case can very easily be achieved by creating a new variant (https://project.pages.drupalcode.org/gitlab_templates/info/variants/#cre...).

Given the flexibility that we already offer in the templates, the variants offered and how easy is to add them, I even question whether we need this issue at all as anybody wanting to test against a LTS can just change one variable (for the previous major composer task) or create a variant.

Test comment [ignore]

Reading the comments in #13 and #18-23 it seems like this issue is not going to be progressed? if so, can we close it?

Not sure why I didn't close it in #23, but yeah, I think we should close it.

fjgarlin → closed merge request !209