It would be nice to see a "last updated date" for the CVS HEAD of each module/theme. This way, users who aren't pulling the module from CVS (but instead downloading the nightly tarball) would know, at a glance, whether updates have been made so they can decide whether to download the newer version or not. It would be especially beneficial to determine whether modules/themes have been upgraded to comply with any API changes.

Comments

killes@www.drop.org’s picture

killes@www.drop.org commented

We've got a cvs mailing list and mailed issues for modules. Should be enough. You can also check the updated date through cvs itself.

TDobes’s picture

TDobes commented
Status: Closed (won't fix) » Active

I think you're missing the point.

When fixes/new features land in CVS modules, there is no uncertainty as to whether or not they landed. This fact is easily communicated to users by reading issues or using the cvs log as you mention. However, there is a great deal of uncertainty as to when the module tarball has been rebuilt. This is why I asked for the "last updated" timestamp. I am a bit hesitant to point end-users to obtaining copies of a module through cvsweb, as it can cause confusion if they are not familiar with the concepts of branching. Therefore, I find myself writing things like "the changes should show up in the tarball within a day or so." Alternately, I can tell users the version number of the updated file and ask them to check the $Id tag in their downloaded files with a text editor... but this involves the user repeatedly downloading until the tarball has been rebuilt.

This is why I thought a timestamp would be a superior solution. The user would be able to look at the time when the change was applied (by seeing the timestamp on the "fixed" message in the corresponding issue) and know that any tarball generated after that time would include the change. No repeated downloading; no guesswork; no confusion on attempting to explain the difference between HEAD and a DRUPAL-4-X branch to an end user. Do we have a better method of accomplishing this with which I am not familiar?

moggy’s picture

moggy commented

I posted a patch that changes the dates displayed from the date of creation of the release to the last modified date on the actual file.

http://drupal.org/node/27341

I find that a much better solution. You see I don't really care that the Project 4.6 was released in may 2005, but I do care about whether it's been fixed yet. If the date reflects when it was last modified (ie updated) then I can see instantly and download it all from one page, without having to faf around in the cvs repository or recieving email about stuff I'm not really that interested in.

dww’s picture

dww
we/he/they
commented
Version: x.y.z » 5.x-1.x-dev
Status: Active » Fixed
Anonymous’s picture

(not verified) commented
Status: Fixed » Closed (fixed)