Version updates should be made to default-ref

Hi,

We have exactly what you are describing running daily: https://git.drupalcode.org/project/gitlab_templates/-/blob/main/.gitlab-...

We use instance wide variables with the recommended release.

In this case, we delayed the push to all contrib of the last tag (or main) due to some breaking changes introduced in core 11.2 which would have made almost all contrib tests start failing. We did some fixes, core did some fixes, and contrib was unaffected thanks to not releasing the latest versions. We normally tag and update default-ref more frequently but in this case we wanted to be sure before doing the switch.

See what when into the latest tag to have an idea: https://git.drupalcode.org/project/gitlab_templates/-/blob/main/CHANGELO...

The last core security release is 11.1.5, which is what we have and check in the code: https://git.drupalcode.org/project/gitlab_templates/-/jobs/5829882#L56

So, all in all, it really seems to me that you just want what “main” offers, which is latest versions.

We’d rather wait and be cautious before releasing a core version jump to all contrib, specially knowing that it would cause issues and generate even more confusion.

Thanks for the really informative response! I appreciate why it's behaving the way it is now. The next minor test means that there is still coverage for 11.2, even though it's technically 11.2.x-dev.

It's not obvious that opting into previous minor is actually opting into the latest security release of the previous minor. Though I think that most of the time that would be the same as the previous minor generally only receives security releases.

I guess in the case of holding up the change for 11.2, it might have been worth back porting 10.5.1 to default-ref. But that's pretty minor in the grand scheme!

So, all in all, it really seems to me that you just want what “main” offers, which is latest versions.

I think there is a valid case for stability of the framework, but latest releases of core. But the issues with core 11.2 make sense why it wasn't done in this case.

To be honest, if you check the changelog, this has probably been the longest without producing a tag and moving default-ref.

Having said that, I tagged yesterday 1.10.0 before you created the issue, and I was planning to make it the default-ref today (as yesterday it was the end of my day).

I will announce the change in the #gitlab channel, so you should be seeing the newer versions from today 🙂

Thanks andrewbelcher for starting this issue, even though in fact there are not going to be any changes to the code, we could still improve our documentation if there are things that are missing or unclear, or just hard to find or not obvious. Could you take a look at the documentation site and see if there are things that could be improved in light of this thread. You have obviously taken some time to think this through, which we appreciate, so a new pair of eyes on the docs could be useful.

One thing that may be useful is if we could re-generate the variants page with the current values of those variables for 'default-ref' and for 'main' so that you could see exactly what is being tested. This could be done as a manually triggered job as part of fhe process when we bump the core versions. The Composer job logs always show this info, so it's in the jobs, but would also be useful in the docs too.

We have 📌 Documentation pages Active for continual improvements.