Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 UTC on 18 March 2024, to get $100 off your ticket.
On the Modules page
http://drupal.org/project/Modules
maybe on a separate tab, I would like to see a table with Drupal Versions across the top, Modules down the left side, and in each cell a module's level of support for the Drupal version.
I would be willing to chip in $100 towards this effort.
Comments
Comment #1
dwwsounds good. i'll work on it. please contact me about the sponsorship. for each cell in the table where a project has a release, we should include a download link. then this tab would be highly useful, in addition to informative.
Comment #2
sethcohn CreditAttribution: sethcohn commentedI really like this idea.
All of the data is currently tracked with one exception, which is actually very useful info: the 'level of support'. I probably spend more time figuring out the current support level of a module before I use it than finding the code itself. There are modules (and themes) I won't use, for example, because the author makes clear they aren't interested in support for it, so I'd rather find code that someone takes some responsibility for, instead of embracing potential deadends later.
It would extremely nice to know Module X is unsupported as of version 4.X, orphaned, commercially supported, has website devoted to it, part of Civicspace, requires a core patch, requires X patch, etc, etc.... Adding freetagging or multiple selection box would allow this to be tracked easily.
Comment #3
dwwas i just wrote in http://drupal.org/node/65975 as i was marking it duplicate with this issue, i think to provide the kind of info that either of these issues requires, we'll need a new tab on the project node for authors to input this stuff. both #63491 and #65975 will just display this info in different formats on different pages as neccessary. basically, it could just be a form with an identical fieldset for each version that the project has been branched for. here's a first draft for the fields for each version:
then, on the project page itself (the view tab, if you see view vs. edit), we could generate a fairly detailed version of this table (including links to the downloads) and do away with the "Releases" section entirely. on the main project listing pages, we could do a more slimmed down version of this table (as originally proposed).
in terms of implementation details: i'm not sure if we should cram all this into the existing {project_projects} table, put it in {project_releases}, or make a new table for this. i think i'd prefer a new table, since we might want to be able to store this kind of info even for version/project combinations that don't actually have a release associated with them (e.g. the "do i want tarballs for this or not" checkbox). however, there *is* a lot of overlap with project_releases, and it's obviously related to that, so perhaps that's a good place. also, some might complain this should just be on the edit tab, but i disagree. that form is already way too long IMHO, so i'd rather keep this on a separate tab (which only shows up for project maintainers and site admins, anyway).
Comment #4
dwwoh yeah, and we need a way to keep this info from getting stale. ;)
Comment #5
Crell CreditAttribution: Crell commentedBig +1 on the concept. I like the idea of putting it in the module developer's hands. The default should, actually, be "unsupported". For it to be anything else, there needs to be a branch/tag in CVS for that version.
This would ideally be on the main module list page, not just on the module view pages. Visually, something like:
OK, so my ASCII art needs work, but you get the idea. :-) Color coding would help, too. This would also allow a lot of extra searchable fields.
And, random idea here, could this tie into the periodic calls for an "endorsed" or "gold" repository for modules that are especially recommended and supported (for some definition of especially)? Perhaps another status (first column) value that only Dries/drumm could set for "Endorsed"?
Comment #6
Crell CreditAttribution: Crell commentedOh wow that didn't render properly. Gr. Well, let me know if you want a screen mockup of what I mean. :-)
Comment #7
dwwyes crell, bad ascii art and all, i think i know what you're talking about. the main idea is a big table (grid, matrix, whatever you want to call it) of modules and version info, so folks can easily find what they're looking for, see what's compatible where, etc, etc. i think it'd all be more compact if the version numbers were just headers on columns in the giant table, and the cells in the table looked something like this: (for example, the cell for project module's row under the 4.7 column)
see http://drupal.org/node/58066 for ideas about project getting release info directly from CVS tags. i'd rather contrib modules could tag themselves with something like "4_7_1-3" for the 4th release (counting from 0, of course) based on 4.7.1 core, and then the download link would look something like download 4.7.1-3. i'm not sure exactly what the best version numbering scheme/format/convention is for this, but clearly we don't want to use 4.7.x for each contrib, since that'd get confusing. i suppose we could number them "4.7.x-3" to show it's the 4th release that's compatible with anything from 4.7.x. drupal at least maintains API compatibility within a stable release like 4.7.x. but, this discussion belongs in #58066, not here.
the idea of the "golden contribs" ties in nicely, too, good point. that shouldn't be hard at all. we could just add a new permission "endorse projects" and then the drupal.org admins can decide what role(s) that permission should be granted to. we should probably keep it a checkbox per branch, not just per project. we could display this either with color, sorting the table, or as an additional word or link in the cell for that project/version pair.
open questions:
anything else? everyone happy with my proposal for what the cells in the table should look like? seems like we're awfully close to being able to just generate a patch... most of the design is done.
Comment #8
simplulo CreditAttribution: simplulo commentedSounds good. You guys are going to be bigger customers of it than me, so I'll trust your judgment. I just have an immediate need to assist the owners of a couple of sites make the decision to move to 4.7.
Comment #9
hautesauce CreditAttribution: hautesauce commentedWould it be possible to add a 'Supported Databases' column to the matrix ? One of my pet peeves is finding
a module that is supported under 4.7 NOT support Postgres. I have even encountered a module or
two that has support in theory for Postgres, but uses DML written specifically for MySQL !
Comment #10
dwwre: supported DBs -- great idea. thanks for the addition.
i'll probably start tackling this issue as soon as i finally get http://drupal.org/node/58066 (real release versions for contrib) done, which is more important to me at the moment (and will have implications on how things would work in here).
Comment #11
Crell CreditAttribution: Crell commentedI think the list of release nodes we now have is sufficient for a "supported matrix". If a module isn't supported, it won't have a release node or its node will be unpublished. The only item remaining here then is SQL server support, which is being actively discussed on the dev list again. Marking this fixed. If desired the SQL support feature should be opened as a new issue.
Yay, dww!
Comment #12
dwwactually, no, this isn't really fixed yet. we'd still need to support a big table like this, and i still think it'd be a good idea to see everything at a glace. but thanks for the kind words. ;)
Comment #13
Gabriel D CreditAttribution: Gabriel D commentedInteresting idea. Have you got it fixed by now? Would be interesting with an update.
Gabriel, Web Programmer currently working on the hypothyroidism natural project.
Comment #14
aclight CreditAttribution: aclight commentedWith the new project release download tables implemented in #176776: GHOP #55: Make release summary table UI look more like update(_status)? report, we've gotten a little closer to what's been outlined above. However, getting Views integration with the project module (see #76726: Refactor project module to use Views [meta issue]) will pretty much be required for us to ever hope to finish this issue. Given that we haven't seen any activity on this issue for over a year, I'm going to set this to postponed until we get Views support for project finished.
Comment #15
aclight CreditAttribution: aclight commented#281708: Request a Module Availability / Comparison Table along side the "browse by category" etc. tabs has been marked as a duplicate of this issue.
Comment #16
John Bryan CreditAttribution: John Bryan commentedThanks aclight for putting in the dupplicate issue link.
My post
The "supported" bit sounds a good idea for the project details as equally usefull information could be displayed from information already available and therefore avoid complicating the matrix.
In a simple lookup table - having just one item of text info is best and personally I think that would best as the latest release date (rather than version number I first suggested) as unfortunately there can be a dozen plus revisions within the same version number. I.e. easily as possible see if there are new releases of modules you use. An alternative would be to track whether modules have have been updated since the matrix was last viewed and indicate with an asterix freeing the text of the cell for other info such as version number or supported status.
Comment #17
Crell CreditAttribution: Crell as a volunteer commentedGoing out on a limb that this is no longer relevant... :-)