Over at #311949-24: Provide us with core developer releases I proposed that for some projects, it might be nice to group the version options under the core compatibility heading for the corresponding release nodes. So, instead of:
6.x-1.0
6.x-1.0-beta1
6.x-1.0-rc1
6.x-1.x-dev
5.x-1.2
5.x-1.1
5.x-1.x-dev
...
We'd have something like:
6.x
6.x-1.0
6.x-1.0-beta1
6.x-1.0-rc1
6.x-1.x-dev
5.x
5.x-1.2
5.x-1.1
5.x-1.x-dev
Furthermore, it'd be nice if maintainers could somehow sort these groupings, to hide the less relevant releases from the top of the list. In the case of #311949, that'd mean putting the 7.x options below 6.x and 5.x (but probably about 4.7.x -- who knows).
This is related to #97568: allow maintainers to restrict choices for "Version" in new issues/replies but different enough that I wanted to make a separate issue about it.
Comments
Comment #1
catchOnce they're grouped, we could also run http://drupal.org/project/hierarchical_select to make it nicer narrowing down too.
Comment #2
drummComment #3
drummI plan to deploy this along with #3089291: Group issue version “series” by branch instead of API compatibility soon.
Here are examples for the core, semver_example, and automatic_updates project:
Comment #4
drummThis code is in project_release.
Comment #5
dwwLooks great, thanks! Glad to see this issue finally getting some love. ;)
We could sure use it in here... here's the project_issue version selector for comparison....
Comment #8
drummThis is fixed in project module, for Drupal.org deployment, watch #3089291: Group issue version “series” by branch instead of API compatibility.
Comment #9
drummTurns out core is not capable of optgroups for list fields: #1180992: [D8] list_field_validate() doesn't seem to accommodate select lists with <optgroup>