"Download latest release" often misleading

Nedjo's original comments above appears to be a slightly different but very related issue to what I'm submitting, so he asked that I go ahead and post my comments here. I have copied and pasted Issue 3 from my posting at http://drupal.org/node/60122. Here goes:

When I choose Filter by version: and 4.7.x from the dropdown menu, I've noticed that some modules have incorrect versions listed if you dig down a bit.

For example, if I look at the very first contributed module on my screen, which is Atom, I can run my mouse over the Download link and at the bottom of my Internet Explorer browser in my Status Bar, I see that the version to download is 4.7.0 as in http://ftp.osuosl.org/pub/drupal/files/projects/atom-4.7.0.tar.gz. However, when I click on Atom, I see under Releases that the latest release is actually for 4.6.0 as in Download latest release (4.6.0, 07/04/2006 - 17:15, 9.39 KB).

Adding to this issue is the fact that when I click View other releases, it shows me that the 4.7.0 version was last modified on April 9, 2006 while the 4.6.0 version was last modified on April 7, 2006, a difference of two days. This tells me that the 4.7.0 version is in fact the most recent but that's not what is being presented at Atom.

I could understand it if perhaps the code called for the latest stable Drupal version, 4.6.6, to then list the latest matching contributed modules' version on the modules page with a default of, in this case 4.6.0. But that doesn't seem to be the case because if one goes to the EventFinder module, one can see that it lists CVS, not 4.6.0, as the latest under Releases.

Another example you can follow (in case the Atom module gets updated and the above info is then no longer valid) is the Event module.

Under Releases, http://drupal.org/project/event shows:
Download latest release (4.6.0, 07/04/2006 - 18:15, 108.29 KB)

while view other releases shows:
Event 4.7.0
Download: http://ftp.osuosl.org/pub/drupal/files/projects/event-4.7.0.tar.gz
Size: 97.52 KB
md5_file hash: c879070e07cd51a3e467ed2190f66cc5
First released: January 5, 2006 - 02:20
Last updated: May 8, 2006 - 22:00

Event 4.6.0
Download: http://ftp.osuosl.org/pub/drupal/files/projects/event-4.6.0.tar.gz
Size: 108.29 KB
md5_file hash: 11ddf39a5ebfb90e8b5c24973340344b
First released: April 24, 2005 - 21:15
Last updated: April 7, 2006 - 18:15

Clearly, the 4.7.0 version is dated May 8 while the 4.6.0 version is dated April 7. Download latest release (4.6.0, 07/04/2006 - 18:15, 108.29 KB) should relect 4.7.0., the more current release.

"latest" is just the wrong word for the link. project maintainers get to select the "default version" for issues and downloads. we should just call that link "download default version" or something. none of this date-based stuff makes any sense at all. people who are trying to download know what version they need, that's all that matters. the "latest" release is of no concern whatsoever, for some of the reasons you've mentioned above.

i say rename the link, rip out any code trying to do anything smart with versions, and just let people sort by versions in the module pages and get what they need. or even, just remove this 1st page link entirely, rename the "download other releases" to "downloads" and always present the user with whatever versions are available.

sorry, i meant to say "rip out any code trying to do anything smart with dates", not versions... ;)

geeze, if only someone would review http://drupal.org/node/29105 so i can commit that and get issue followup previews working again on drupal.org. ;) (sorry nedjo, i couldn't resist).

I agree that "none of this date-based stuff makes any sense at all."

You wrote, "project maintainers get to select the "default version" for issues and downloads." Why would a project maintainer select an earlier version (4.6.0) over a more recent stable version (4.7.0) as the default version for their contributed module's download? It would seem to me that if they've provided a stable 4.7.0 module, that it would then be chosen by them to become the default version for download.

Furthermore, if I select 4.7.0 from the drop-down box, I would expect to only see 4.7.0 modules for download and not any 4.6.0 or CVS modules. Otherwise, why have a drop-down box if it doesn't present the way it's expected?

Anyway, I agree that your suggestions would help correct things and make them more presentable.

Thanks!

Why would a project maintainer select an earlier version (4.6.0) over a more recent stable version (4.7.0) as the default version for their contributed module's download?

nearly all modules live in "cvs", i.e. on the trunk of the CVS repository. a project contributor might be maintaining a module that was originally written for 4.6, and currently, that's the only branch where it really works. however, they're actively making commits to the cvs trunk, trying to port to 4.7.x. if it was *only* based on date, then the "cvs" version would always be listed as the most recent, even though that's not the version the author thinks is the one anyone should really be using.

anyway, further evidence for the idea that date-based displays of downloads is the wrong approach for us, and we really just need to do a better job of presenting the appropriately versioned tarball depending on the view of the projects.

fixed via http://drupal.org/node/89538 and http://drupal.org/node/89539