automatically insert human-readable version into .info files

@merlin...
re 1: already implemented in the above patch, and webchick agreed in IRC not to fight this. ;)

re 2: so, something like:
core_api_version = 5
or
core_api = 5
or
core_compatibility = 5
or... ?

also, we use "5.x" everywhere else... perhaps we should stick with that?

new patch that applies cleanly to the end of DRUPAL-4-7--2 branch
(my watchdog cleanup caused the previous to not apply anymore).
also, makes the comment at the top of file_find_youngest() better for explaining what's up with the info_files array...

at merlin's suggestion, add a comment for the autogenerated entry

here's a sample .info file from my local test site:

; $Id: signup.info,v 1.1 2006/11/13 05:14:44 wright Exp $
name = signup
description = allows you to signup for events
; version added by drupal.org packaging script on 2006-11-16
version = "5.x-1.0-beta2"

unconed had some good feedback in IRC on some of the implementation details.
i'll clean this up based on (most of) his suggestions. ;)

fix_info_file_version() is a lot nicer now. ;)

it's not quite as simple as steven wanted, since i still want to preserve the location in the file where the author put version (in case they have a comment next to it or something), but this is much better. ;)

thanks!
-derek

UnConeD suggested just leaving any references to the existing version line alone, and always appending the corrected version at the end of the file. since it comes at the end, the ini parser will always use the most accurate value, but this avoids any of the complications of trying to change what's there. we just open the .info file for appending and add our data.

here's a sample of the new signup.info file this is generating on my test site:

; $Id: signup.info,v 1.1 2006/11/13 05:14:44 wright Exp $
name = signup
version = "$Name: DRUPAL-5 $"
description = allows you to signup for events

; version added by drupal.org packaging script on 2006-11-17
version = "5.x-1.x-dev"

i added the extra newline at the front of the stuff i'm appending to protect us from .info files where EOF is at the end of the previous line, not at the start of a new one. if i slurped in the whole contents i could avoid this, but a) i don't care about 1 extra newline in some cases, and b) reading what's there was the complication this approach is trying to avoid anyway. ;)

any more objections, or is this finally RTBC?! ;)

thanks,
-derek

p.s. natrak: now that we're appending, and could potentially have 2 different version lines in the same file, the comment about "Added by drupal.org packaging script..." is definitely a good thing to leave in there.

committed my latest patch to DRUPAL-4-7--2 and updated d.o.

they get exactly as much version info as the release node contains. if you insist on using HEAD for anything, no one (not even the packaging script) knows what version it really is.

for new projects since the system went live, when the maintainer adds a release node pointing to HEAD, they still have to specify version info. in that case, the packaging script will add all the info it has. however, the historical HEAD releases were a huge problem, and sadly, i had to "won't fix" my own issue about *not* auto-creating release nodes during the live deployment on d.o (so we could have forced the maintainers to at least specify a core compatibility when creating a release node for HEAD):
http://drupal.org/node/93502

meanwhile, i have plans for making it easier/better to edit existing HEAD release nodes so that you can provide more version info, and even switch the branch they're pointing to if another branch exists for your project with the same version info which doesn't already have a release node pointing to it:
http://drupal.org/node/89699

enjoy,
-derek

right. the packaging script will only add the info it knows from the release node.

sorry you can't currently edit the HEAD node to provide more info. that's what http://drupal.org/node/89699 is about.

meanwhile, you already *have* 5.x releases for OG and Devel. so who cares about the HEAD release? no one should be using that, anyway... one of the many benefits of the new system is there's *no* reason anyone should ever have to rely on the evil, moving target, ambiguous "HEAD" for anything anymore.

HEAD is for the module maintainers to prepare the next release series, nothing more. if the next release series is new features for older core, when you're ready for the public to start using it, you make a new branch and generate releases off of that. personally, if it wasn't for the existing issues in the queue, there wouldn't be any HEAD release nodes at all. i would have been happy to completely prevent people from creating new release nodes pointing to HEAD, but i would have been lynched for that. ;) oh well, i can't have *everything* my way... ;)

-derek