Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.If a user wants to review a project in the Project applications queue of drupal.org based on versions.
Currently there is a Version filter available, however it does not populate any version values such as 7 or 8.
I am attaching a screenshot. Please ignore, if this is not an issue or already been addressed.
| Comment | File | Size | Author |
|---|---|---|---|
| projectapplications.png | 108.37 KB | jack_ry |
Comments
Comment #2
jack_ry CreditAttribution: jack_ry commentedComment #3
jack_ry CreditAttribution: jack_ry commentedComment #4
jack_ry CreditAttribution: jack_ry commentedComment #5
apadernoThe field shown in the screenshot is not for the projects being reviewed, but for Drupal Project applications as project. Since the project doesn't have committed code, it doesn't have any value for that field, and the single issues cannot even set a value for that.
Probably, that filter should not appear in the view, in the same way creating an issue for that issue queue doesn't allow to set a value for the field.
Comment #6
jack_ry CreditAttribution: jack_ry commentedHi kiamlaluno,
The filter shouldn't appear in the view. I understand this is project application queue which still needs review. I assumed that this filter was used there to filter projects for review based on versions. Looking at the name would suggest the version but still if someone is interested only on projects in drupal 7.
Comment #7
apadernoThe Drupal version is given in the issue title: For example, [D8] means Drupal 8. Unfortunately, searching issues using [D8] lists also issues with a title starting with [D7].
Without writing custom code, it's not possible to do things like this. If there is support, I am willing to write a custom module that would make project application reviews easier. That is not a call for webmasters, though.
Comment #8
drummIn the long run, Drupal core version should be less relevant. Drupal 8 modules are really Drupal 8 or later, since there is API compatibility between Drupal 8 and 9. I don’t think more custom code to support this in the meantime is worth it.