Tweak the list of core versions for the issue version field, so 11.x is at the top

https://git.drupalcode.org/project/project/-/blob/132a1ca69dd97276a4d03f... is where this sorting happens.

We could swap in a new sort function there, since better MRs will ease the transition to issues in GitLab. What I could use help with is thinking through a replacement/layer-on-top-of version_compare() that sorts as expected.

AFAICT you can fall back version_compare() unless BOTH left & right are 11.x and 11.0.x (though not sure what order they come in, might have to check both orders).

so:

//  By default, version_compare() returns -1 if the first version is lower than the second, 0 if they are equal, and 1 if the second is lower. 
if (left == 11.x && right == 11.0.x) {
  // We want 11.x to be greater.
  return 1;
}
if (left == 11.0x && right == 11.x) {
  return -1;
}
return version_compare(left, right);

N.x releases should be sorted the same way in any case, so we shouldn’t hard-code 11

I'd have hoped we'd have the `main` branch sorted by the time 12 comes around!!!!

But yeah, that gets a bit more complicated.

We can't say `preg_match('/\d+\.x/')` because that would catch the old versions 5.x etc.

But `preg_match('/\d{2,}\.x/')` should be ok.

So we probably want to say that `preg_match('/\d{2,}\.x/')` is greater than anything.

When 12.x comes around there won't be an 11.x around any more, so we don't need to think about that.

AFAICT you can fall back version_compare() unless BOTH left & right are 11.x and 11.0.x (though not sure what order they come in, might have to check both orders).

Plus, doing this, would just cause the problem to come around again when we open 11.1.x in a few weeks.

This should not be hard-coded to 2 digits as well. For a contrib module with 2.x and 2.0.x, sorting should be consistent.

When 12.x comes around there won't be an 11.x around any more, so we don't need to think about that.

Release branches are permanent, so 11.x is not going away.