Important usability issue - What version am I using?

+1 on the concept.

So you're saying that the update script would put a new version number into the db? Good idea.

Let's see some code.

We probably need a small array of schema => releasename. Schema is already in database...

drupal.module already has a constant with the version number. I'm not sure what this means, though.

+1 for the idea. useful also for users when needs to upgrade after a security hole.

Also displais this informations on the admin page. Maybe just before the line
"Welcome to the administration section. Below are the most recent system events."

I agree that it should be easier to know the version you're running, but it should also be hidable. Some consultants like to be able to completely self-brand the system, and having it say "Drupal 4.x" in big letters makes that a wee bit more difficult. :-)

People who'd like to lay claim to our work should be educated with pointy sticks.

mgifford: don't you think that having version number public available
(in a meta tag) could be a security issue?

Think about the version used is a bugged one that hasn't been patched..
Displaying version number to everybody could make a cracker life really easier..

I think that display version number on the administration page could be enought.

About consultant which want to hide informations: maybe we can wrap version
number in a theme('version', $version) and let themers override that function.

eight people who think this is a good idea. right. So where is the code. As killes points out, saying that something is needed, does not solve anything.

We all *know* that we need this. So, code it. :)

I think it would be nice if anything done in this direction can also be used by contrib modules/themes.

Imagine that core and contrib stuff includes a file named "item.version". This file could include the item name, version, date and maybe more information such as dependencies, etc.

For core, you could print this information somewhere on an admin panel (maybe admin/settings). For modules, in admin/modules and for themes in admin/themes.

Then, the project module could generate some kind of feed with that information for latest released version. So that feed could be retrieved from Drupal sites and could be used to mark in red (or something) out dated items in admin/settings, admin/modules and admin/themes.

An additional benefit of such "item.version" files could be that there would be no need to load PHP stuff when looking for modules, which would safe a lot of memory requirements only to visit admin/modules.

The format of the "item.version" file could be XML, which seems suited for transfering information across systems.

Your if empty is unneeded. variable_get('drupal_version', array('text' => '4.7r3', 'date' => '20060130')) will fill the var, if it is not set yet.

WE also really need a variable_set in the update.inc, though.

Wouldn't it be better to place version information on a common central place? There's already a constant in the drupal module. ...or is that a completely different story?

I wasn't suggesting that we aid and abet people in misrepresenting Drupal as all their own work. (Hell, I can recognize Drupal by its URLs these days.) But one of Drupal's big advantages is how brandable it is. I think it was Dries (although I'm not sure of that) who commented once that you can run a Drupal site without the word "Drupal" apearing in it anywhere, which was a good thing. I agree, and that's a feature we should keep.

Short-term, the theme() function sounds like an interesting approach. Long-term, we really need better versioning declaration for both Drupal core and contrib modules. +1 on keeping that information limited to the admin area, though, for security reasons.

There is version defined in drupal.module:

define('VERSION', '4.7.0');

This code needs to be cleaned up.

You would have to fix drupal.module as well (remove the VERSION constant definition).

I believe these constants ought to be defined on a global file, maybe bootstrap.inc?

Also, what do VERSION_DATE VERSION_CVS mean? Which file do they refer to?

And how to you plan to keep this information up to date? Which events should trigger changes in these constants? Probably this needs some kind of documentation.

Not sure how the LICENSE.txt file gets inserted into packages, but that process could also generate a file named VERSION, maybe in XML format (easier to extend). Then you need a function to parse that file and decide where do you wish to print it out.

Benefit is what you do for core, also works for contrib stuff.

At a later time, an additional "feature" could be added. Let's say these files are stored on a central server too, for all project releases. Well, you could add a cron step in drupal core, so drupal based sites could compare their VERSION files with latest releases, so admins could easily know when they have installed outdated packages.

please check the installer system. It will need .install files for all projects. That file will contain a version.

ok, Mike (mgifford) and i starting chatting on Skype about his (and others i guess) idea about version control... he asked for my $0.02 worth... so i went off on a "rant".. and came up with what i think might be a couple pretty powerful ideas...

Mike figured i should post my suggestions here... so a bit messy .. biut here it is... Mike's comment are still quoted with his name... but name stamps have been removed..

Perhaps.. if i get a chance to mock something up... will repost as a new project ????

============================

well after a quick read.. my $0.02 worth (and i always have an opinion) would be to have module ver numbers pulled out and shown in admin/modules

and possibly include a couple things listed in same location like bootstrap.inc

would simply need to set module DEFINEs in the module and stat that as part of std module development

then have those read when other mod info is read to build admin/mods page

i would have said simply key off CVS string on top at to of module... but they dont seem to make sense here... but they could if drupal cvs set up differently.. currently my 4.7 drupal.mod shows VER = 4.7.0 (which isn't that accurate since it is post beta4

and CVS v = 1.116

possibly could show both, i guess, but likely not needed

and only admins who can admin/modules will have visibility

i bet an hour or 2 of code to pull out cvs "v" from modules

which is maybe more detail than required.. but likely better in many ways than simply having a manually edited DEFINE with no detail.. like 4.7.0 ... which is clearly not up to date.

then there could be the concept of a CIL... ex-Nortel term... compatible issue lineup

which would map the versions of core modules to a release...

EG - Version 4.7Beta4 would = drupal.mod 1.116, blog.mod 1.54, story.mod 1.34, etc....

ok.. maybe more than my $0.02 worth.. but hey... you asked.. well sort of asked

ok.. i got more.....

so drupal.org would need to publish a txt file with the lineup that matches a release.. like the CIL i just suggested.. then code to display mod versions could key off that file and highlight on the admin/module page any module that doesn't match release

these things are all pretty simple.... just not sure that is what anybody wants.. but i would sure find it useful

conceivably modules could spawn from this to do things like what CivicSpace does.. you could "stamp" your own version number to any set of modules and replace the CIL.txt file with this.. you could now see what modules are/aren’t part of YOUR release and which are not at correct release

i think the only parts of this required by core are: publishing of CIL, addition to admin/module page

everything else like add-ons later... like highlighting out of version modules or stamping releases

ok... done.. again..

Mike Gifford: 16:24:06
Totally like this idea "numbers pulled out and shown in admin/modules"

oh.. ok.. thought maybe i was missing the point here :)

Mike Gifford: 16:25:00
There is at least one module that shows the cvs string as the version.. Not sure which one, at the moment mind you..

since i have so much free time on my hands.. maybe i'll hack up something later.. can't be too hard

i think the REALLY cool part of this would be the highlighting of versions out of line... and stamping a release...

that way developers can have their own release control

with their own module lineups..

Mike Gifford: 16:27:02
You gotta put this thread down on the forum or issue tracker somewhere

I haven't had time to create a proper addon module for this yet, but here is what I did for a very limited version control in the system module which I needed as I am in the (long overdue) process of upgrading a couple sites from various versions of Drupal and converting from other legacy CMS implementations. I say very limited because it is only looking at the .module and not any of the countless other files that periodically require updating.

It reads the first couple lines of each module and parses the cvs line. The benefit of this approach is that nothing has to change, all existing modules work, the problem is that its slower and more cumbersome than it needs to be. I also like to see which modules are in core (I forget) vs modules directory vs sites subfolder so it adds css tagging where I can add an icon. Future plans for this were to indicate which modules have SQL tables associated with them and possibly check the cvs status on drupal.org

In function_system_modules()...

-    $form['description'][$file->name] = array('#value' => $file->description);
+    if (substr($file->filename, 0, 4) == 'site') {
+      $form['description'][$file->name] = array('#value' => '<span class="module-site">' . $file->description . '</span>'); 
+    } else if (substr_count($file->filename, '/') > 1) {
+      $form['description'][$file->name] = array('#value' => '<span class="module-addon">' . $file->description . '</span>'); 
+    } else {
+      $form['description'][$file->name] = array('#value' => $file->description); 
+    }

+    $form['vers'][$file->name] = array('#value' => _get_cvs_line($file->filename));

In theme_system_modules()...

    $row[] = form_render($form['description'][$key]);
+    $row[] = form_render($form['vers'][$key]);
    $row[] = array('data' => form_render($form['status'][$key]), 'align' => 'center');

    if (module_exist('throttle')) {
      $row[] = array('data' => form_render($form['throttle'][$key]), 'align' => 'center');
    }
    $rows[] = $row;
  }

-  $header = array(t('Name'), t('Description'), t('Enabled'));
+  $header = array(t('Name'), t('Description'), t('Vers'), t('Enabled'));

at end of file, add...

/**
 * Opens a file, reads the first few lines until it finds the cvs
 * identifier '$Id:', and returns all or part of that line based
 * on its position (split) in the line.
 *
 * @param $filename
 *   The name of the file to read
 * @param $part
 *   The part of the line needed. Values include vers, date, 
 *   author or line (defaults to vers).
 * @return
 *   All or part of the found line.
 * @author Gestaltware
*/
function _get_cvs_line($filename, $part='vers') {
  if (!$filename) return "n/a";

  //= get line
  $open = fopen($filename, 'rb');
  if ($open) {
    $line = 0;
    while (!feof($open)) {
      $cvs = fgets($open);
      if (strpos($cvs, '$Id:') !== FALSE) break; //got CVS line
      if (++$line > 5) break; //sanity check
    }
    fclose($open);
  }

  //= process line
  if (strpos($cvs, '$Id:') === FALSE) return 'n/a';
  if ($part == 'line') return rtrim($cvs); //no processing required
  $cvs = str_replace("// ", "//", $cvs); //clean up optional space
  $cvs_parts = explode(" ", $cvs, 7);
  switch ($part) {
    case 'date': return $cvs_parts[3] . ' ' . $cvs_parts[4];
    case 'author': return $cvs_parts[5];
    default: return $cvs_parts[2];
  }
}

This is fixed in cvs via .info files and admin/logs/status.