Closed (fixed)
Project:
Drupal core
Version:
5.x-dev
Component:
other
Priority:
Normal
Category:
Feature request
Assigned:
Reporter:
Created:
13 Apr 2005 at 16:31 UTC
Updated:
16 Dec 2006 at 02:10 UTC
Jump to comment: Most recent file
There's no easy way for a site administrator to tell which version of Drupal software his site is running. This is particularly a problem when an administrator manages multiple sites at multiple hosts. The problem becomes even more exacerbated when the same admin only has limited time to update the software on sites, resulting in confusion as to just what version is running where.
While there are a lot of technical solutions to this problem, some of which I'd like to implement, this patch is the simplest and least invasive. It simply adds the CVS release tag name to each file which can take such a tag. An admin can thus look in any file and see which release it is.
This patch is for the core files.
A similar one will be added to a separate issue for contrib files.
| Comment | File | Size | Author |
|---|---|---|---|
| #6 | cvs_name.patch | 34.76 KB | Uwe Hermann |
| releasename_core.patch | 32.8 KB | Chris Johnson |
Comments
Comment #1
matt westgate commentedThis make a lot sense. +1
Let's also output the release tag name somewhere in the Drupal admin section. Maybe on admin/settings?
Comment #2
Chris Johnson commentedYes, I'd like to add some panel to admin that would show the admin which version of the software he was running, as well as which version of the database (update number) he was running. There might be a few other bits that could be added to such a display that would make life so much easier for the harried admin trying to manage many sites and projects.
I'm willing to code it. Just need to get a little buy-in and agreement on features from those who decide what goes in core.
Comment #3
kbahey commented+1 for this patch. It does not solve everything, but is sorely needed.
Dries, I think this should go in 4.6 before its release too.
As for the visibility to the admin, I suggest that each module would have a version attached to it. This version can be the Build Tag/Name, and a date where the tar ball was packaged. Under admin -> modules, each module has this info listed next to it.
Adding the date avoids the problem of retagging in contrib, updates to an existing branch, ...etc. which were discussed in an earlier thread.
If we extend this to the scheme files, it would be easier to track changes needed to the database from one release to the next too.
Comment #4
chx commentedbiiiig +1
Comment #5
Uwe Hermann commented+1
Comment #6
Uwe Hermann commentedLets revive this. I still think it's a good idea. Patch attached.
Comment #7
Cvbge commented+1 on idea.
Critical because many people ask on -support how to check what release they are running...
Comment #8
Samat Jain commentedComment #9
dries commentedIf you want to see what version you are running, you can look into the CHANGELOG.txt.
Plus, I don't think it's useful to add this to every single file.
Comment #10
Uwe Hermann commentedI disagree. I don't run a single site which does _not_ have multiple custom patches applied etc. I simply cannot say "this is a 4.6 site", I need to know exactly which file has which CVS Id and is from which branch. The CHANGELOG.txt won't help anything here. Besides, lots of people remove the *.txt files when installing on a web host (the forums are full of people who don't know which version of Drupal they run _and_ don't have a CHANGELOG.txt on their server)...
Please consider this feature, or mark as "won't fix" again, and I'll shut up.
Comment #11
drewish commentedHow about doing it as a contributed module that simply recursively scans the drupal directory and returns the CVS ids of all the files it finds?
Comment #12
Chris Johnson commentedA Drupal site admin cannot necessarily look into the CHANGELOG.txt file! Only a person with file access to the site host can do that.
Even if one does have that kind of access, it is a royal fscking pain in the neck while administering a Drupal site via the web to then go through the trouble to then access the files through the host. For example, with my favorite host, all access is through WebDAV. If I'm in a Cybercafe or at my primary employer's office, I do not have WebDAV access, although I may well be administering my site via the web from those locations.
CHANGELOG.txt is also dependent upon programmers updating it correctly using accurate and understandable information.
I want to know what release my site is running, and what versions of all the modules are. I don't want to have to browse through all the source files to figure that out. This is basic software configuration information. Virtually every successful program in the world provides this kind of information. Take a look at your web browser, for instance. Firefox, Safari and MSIE all have "about" menu items which tell you specifically which version you are running.
Yes, I can code a contrib module that will read all the files and derive this information. I might just do that. But it really should be part of core and it really should be registered in the database.
Comment #13
puregin commented+1...
Seems like a pretty good idea to me.
It would be nice to have each module return a version string as part of its init() hook. This information could be shown in the table displayed for admin/modules.
I'd suggest the Drupal version could be displayed with the admin/settings info...
Comment #14
beginner commentedComment #15
Chris Johnson commentedThe init hook seems like the right place for modules to me, too. I submitted patches to add that information there about 2 years ago, but they were ignored. :-(
The core files need some kind of version stamp as well, and so does the database version -- although I think that's probably derivable from the update version information.
Mostly just posting to keep this issue alive. :-)
Comment #16
bdragon commentedDrupal 5 has
A) Versions for module files displayed on the modules page.
B) A status report page containing the version number.
That's enough, yes?