Problem/Motivation

The version selector on this issue goes back to 4.7.x-1.0 and has over 20 options.

For Views it goes back to 4.6 and has a scrollbar on my laptop.

Proposed resolution

Only show supported branches in the version selector. This would reduce the number options down to 2-4 for the vast majority of projects.

Remaining tasks

User interface changes

API changes

Data model changes

Comments

catch created an issue.

David_Rothstein’s picture

David_Rothstein CreditAttribution: David_Rothstein as a volunteer commented

Could make sense to remove them eventually (once they've been unsupported for a while); not sure about doing it right away since it would prevent issues like #2687401: [core] Sessions don't work on PostgreSQL after updating to Drupal 6.38 from being filed against the right branch.

Then there are issues like #1016008: Drupal 5 PHP 5.3/5.4 compatibility patch which was filed right around when Drupal 5 was marked unsupported, but could easily have been filed much much later - and which (sadly) I made use of several years later.

What would happen when someone comments on an old issue? Would the version selector just keep the already-selected unsupported version, but not show any of the others?

catch’s picture

catch
he/him
Primary language English
CreditAttribution: catch at Third and Grove commented

#2687401: [core] Sessions don't work on PostgreSQL after updating to Drupal 6.38 should probably be filed against https://www.drupal.org/project/d6lts at this point. Had there been a D5LTS project then #1016008: Drupal 5 PHP 5.3/5.4 compatibility patch could have been filed against that.

What would happen when someone comments on an old issue? Would the version selector just keep the already-selected unsupported version, but not show any of the others?

Yes that bit's tricky - what you described sounds like a good solution. Allow issues to stay at the current version, or move to a supported branch, but not move between unsupported branches or backwards.

drumm’s picture

drumm
he/him
Location NY, US
CreditAttribution: drumm at Drupal Association commented

I suggest considering clearly labeling these with an optgroup. This removes any extra considerations in updating old issues (need the usual allowed values, plus the current value) and allows issues to move around in old versions for the edge cases that need it.

catch’s picture

catch
he/him
Primary language English
CreditAttribution: catch at Third and Grove commented

An optgroup would be a good step forward.

drumm’s picture

drumm
he/him
Location NY, US
CreditAttribution: drumm at Drupal Association commented

A problem here is that 9.0.x-dev is technically not supported. If we keep that under “Unsupported”, #2691889: Add option to remove tagged releases from the version selector should land first, so 9.x isn’t too far down. I could also see splitting unsupported into something like “Future” and “Unsupported”.

xjm’s picture

xjm
she/her
Primary language English
CreditAttribution: xjm at Acquia commented

While an optgroup would be a step, part of the advantage of this issue would be in removing options from the form so that we can add support for multiple branches without it being overwhelming. Optgroups are generally bad for usability. Maybe old branches could be under an "Unsupported..." multiselector in the long term or something? But yeah, issues getting accidentally updated from 4.6.x to the latest version would be disruptive, so it makes sense to avoid that.