Hey

After being referred to this module, i began having tons of ideas and taking notes on them... then i went to sleep, but couldn't, because i kept having more and more ^_^

(haven't installed the module yet nor looked at the code)

So here i am to dump all those ideas - i will start by bringing in the ideas posted at an issue earlier:
some possible definitions bellow...
measurement of portability:
- some modules are not ported, but became part of a new version core (like ImageCache in D7)
- some modules are ported backwards (ie, backport from D7 to D6)
- some modules are ported forwards (ie, ported from D6 to D7)
- some will be ported (as per project page)
- some won't be ported at all
- and for some, we might not have information
measurement of activity (relation to how probable is a module to become unsupported):
- some are active and supported
- some are supported, but not in active development (though functional)
- some are unsupported (no developers around by various reasons, like lack of time, lack of interest)
- some are abandoned (marked as abandoned by the developers)
- some are deprecated in favor of others, within same version (ie, in D6 - Filefield Insert and Insert)
- some are deprecated in favor of others, within different versions (ie, in D7 - jCarousel and Carousel, Thickbox and Colorbox)
- and for some, we might not have information
measurement of priority:
- some would be required or optimal to have/upgrade
- some are entirely optional to have (yeah, maybe the module should provide other info than just upgrading ;))
- some would be critical to have or critical to remove, due to security risks
- and for some, we might not have information
measurement of versioning:
- some are stable (1.0, 2.0, 3.0, etc)
- some are unstable (1.0-alpha1, 1.0-beta1, 1.0-rc1, etc)
- some are in development (1.x-dev, 2.x-dev, etc)
- and some do not say the version (custom modules)
general:
- again, don't forget those without information... (maybe deleted or never had a project page)

so i'm thinking that modules should have thereof, the following tags:
- versioning: stabe, unstable, in development, no info
- priority: required, optional, critical, no info
- activity: active, supported, unsupported, abandoned, deprecated, no info
- portability: in core, ported backward, ported forward, being ported, no port, no info

---------------------

(haven't installed the module yet nor looked at the code)
__replacing modules/themes/libraries with *stuff* __

More ideas:
- add project description, in a collapsed field (so it doesn't takes up space until expanded)
- add project terms that are used at the project page, in a collapsed field (ie, for Update Status, it's Actively maintained · Administration · Modules · Developer · Utility). this can be combined with same fieldset above
- categorize *stuff* (ie, Administration, APIs, WYSIWYG, Shopping, Permissions, etc) - would work by adding a tag with the relevant main category for each *stuff*. this can be combined with same fieldset above
- featurize *stuff* (ie, Toolbar menu, Sidebar menu, Theme settings, Theme editor, Theme overrider, General slideshow, Views slideshow, etc) - would work by adding a tag with the relevant main feature for each *stuff* (attention, not a project feature descriptor). this can be combined with same fieldset above
- add filters to filter *stuff*, like in a catalog: category and feature (as above), installed or not, name, versioning/priority/activity/portability (like in my previous idea)
- add Similar *stuff* tags (a comma separated list of similar *stuff* (the project names), which then Update Status then formats to project URLs, in small font, non-bolded and itallics and sets as a collapsed field, for similar *stuff* review reference)
- add Recommended alternative(s) to *stuff* for cases when the *stuff* is deprecated. should note the best case and select that - can be combined with above as bolded project URLs
- add Optional alternative(s) to *stuff* for cases when the *stuff* is okay, but there are other good *stuff* - can be combined with above as bolded project URLs
- integrate with Plugin Manager (D6 module which was either ported to D7 core or the feature was rebuilt for D7 core) and Drupal 7 Update module / Install a new module feature (by URL) - can be combined with above as a "(Install)" javascript URL for the recommended/optional alternatives

(haven't installed the module yet nor looked at the code)

Yet More ideas:
- extend module to Themes, Translations and 3d party Libraries (through Library and jQ module)
- separate API/UI/Code from DATA
- extend and allow customization of the the way *stuff* is showed: if the *stuff* data was stored within a DB table and read with Views 2.x or still stored as a flat file with read with Views 3.x (API for external data sources), this would be possible; the page itself would be a View
- if storing *stuff* DATA as flat files, store in a massive file, or as individual file for each project, split under project type directories (modules, themes, translations, libraries)
- possibly include both flat files and SQL file to import to DB
- work closely with Similar Module Review group
- create a site for this project and Similar Module Review group
- rename module ? (after all of these changes)

Comments

such site could also include a proper listing of sites made with drupal (verified with firefox wappalyzer), table like, filterable, by using Views

already brainstorming project/site names :P

EDIT: inspecting the XML obtained remotely for projects
ie, Views - http://updates.drupal.org/release-history/views/6.x

if considering support for Views, check on Enabled Modules

StatusFileSize
new306.96 KB
new1.99 KB
new16.27 KB

posting a draft for XML storage - repo.xml (supplied as .txt and gzipped)
this draft has a 2 projects: dummy module and CCK module, with multiple releases.
it validates okay here if you uncomment the tag with schema.

i've add comments to it and noted that many many many XML entries can be fetched directly from the original XML project releases. they have been added to state facts, illustrate possible uses and be a reference guide.

REQUIRED - required entries, nesting important content
OPTIONAL - optional entries, for possible future use cases or stating that can be fetched from release XML
NOTUSED - development reference

and some original XML samples from CCK release history, plus a list of drupal projects.
EDIT: anoter list of projects here

posting draft 0.2 - mainly changes with versioning and which are REQUIRED tags.
that results in some simplicity

made 2 versions:
- the trimmed version, ready for official published contrib modules
- the full version, supporting custom modules

the trimmed version drops copy-pasting of most tags and keeps only the necessary ones, greatly simplifying the file structure.
as result, it gets a dependency on original xml files being fetched (which the module already explores anyways)

using a trimmed version doesn't means custom modules aren't supported. just means developers will write less tags per module.
the missing tags can still be added for custom modules, provided the Update Status module reads those and overrides whatever tags Drupal is finding for such modules.

so, in my draft, the trimmed version would be used 99% of the time, while the full version could be used occasionally for custom modules.
writing a schema draft would resolve documentation issues for that matter.

note:
you will notice multiple versions for each module in these drafts.
but you will also notice only a single major version, accompanied with the development version for that major version.

my plan is to have only those versions listed. minor/patch versions should not need to be added and refreshed on the XML repo, because they don't usually break the modules or mean a rewrite or port no a new Drupal major version.

Upgrade Status module should be smart enough to catch the tag (ie, 6.x-2.5), select the appropriate version from the correct XML (ie, http://updates.drupal.org/release-history/cck/6.x), then choose the most updated version for that major (in this case, 6.x-2.8)
for the cases where we have alphas and betas and RCs, the methodology currently being applied would be used here as well

so even if we have outdated patch versions, the mechanism would still work and provide the right comparisons

now, what if the XML file gets too big, and thus, harder to maintain and cooperatively edit?

new XML method of storage:
- create modules, themes, translations and libraries directories
- place individual project XML files inside the relevant directories, named after the project name/id
- as the whole XML repo is made of smaller files, these could be retrieved from a server (should also be bundled with the module package), with the benefit of supplying updates, without launching new module versions.

(also in case you didn't noticed yet, by having every DATA in XML files, you don't need to touch and launch new module versions every time you need to add another module to the list...)

directory structure:
upgrade_status
-------repo
-------------- modules
----------------------- cck.xml
----------------------- views.xml
----------------------- better_formats.xml
-------------- themes
----------------------- genesis.xml
----------------------- fusion.xml
-------------- translations
----------------------- de.xml
----------------------- pt.xml
-------------- libraries
----------------------- jquery.xml
----------------------- jquery.ui.xml
----------------------- jquery.scrollto.xml
----------------------- colorbox.xml

i'm supplying both the trimmed and the full versions, with dummy and cck module examples for this case scenario.

btw, how about a Libraries API and jQ integration?
Libraries API and jQ bridges in the Libraries (jQuery or not) and their info, Update Status provides update information and comparisons with the help of Core, Plugin Manager/D7 Core updates *stuff* ....

draft 0.3 with support for category, feature, similar modules, recommended modules and alternative modules tags

additional standard fields from the original XML files could also be added in the future, like datetime stamps, for cases when it's desirable to override values, or again, for custom modules.

CVS support built-in the XML files - i'm not sure that is needed at all. i don't know the inner workings, but maybe the module and CVS Deploy do it fine without needing further XML help.

updated custom tags and populated some categories:

  • activity: active, supported, unsupported, abandoned, deprecated, no info (noinfo)
  • priority: required, optional, critical, no info (noinfo)
  • portability: in core (incore), ported backward (portbackward), ported forward (portforward), ported forward extras (portforwardextras), ported major (portmajor), being ported (beingported), no port (noport), no info (noinfo)
  • versioning: stable, unstable, outdated, in development (dev), no info (noinfo)
  • category: Administration, Advertising, APIs, Backup, Blocks, Browser, Calendar, Debugging/Development (Development), Content Display (Display), Content Forms (Forms), Evaluation/Rating/Voting/Sharing (Evaluation), Feeds, Fields/Content Fields/CCK (Fields), Files, Filters, Gallery, Geography, ImageCache, Integrations, Interface, jQuery/Javascript (Jquery), Mail, Menus, Multisite, Node Management (Nodes), Organic Groups (Ogroups), Other, Overlays, Performance/Caching (Performance), Permissions, Players, Profiles, Projects, Roles, Search, Security, SEO/Search Engine Optimization (SEO), Shopping, Slideshows, Spam, Statistics, Taxonomy, Theming, Translation, Localization, Translation/Language/Multilingual/Internationalization/Localization/i18n (Translation), Uploaders, URLs/Paths (URLs), Userpoints, User Management (Users), Utilities, Views, WYSIWYG/What You See Is What You Get (WYSIWYG)... (add more)
  • feature: test module, data manipulation, content rating, ... (add more)

Status:Active» Closed (won't fix)

Sounds like this needs to be it's own module.

humm i'll wait on sun's opinion on that.
maybe some of the features could be integrated on Upgrade Status.

also, i think, if many of these features were to be implemented, it will take many versions for that to actually happen
it would also be best to start with the easy ones and with the XML structure (to avoid rewriting multiple times), and leave the rest for future versions (like Views)

i've came along another awesome module. noting it for reference:
http://drupal.org/project/module_supports

haven't tested yet, but it provides useful information which sometimes developers forget to mention on the project pages.