On Mon, Jan 29, 2007 at 01:45:47PM -0800, Stephen Lau wrote: > My personal vote is to: > - Eliminate the #ident %Z% keywords (since the what(1) string is replaced > by the build, anyway). > - Replace %I% for module versions with the Hg revision number
One thing to note about replacing the ident line is that even files that aren't compiled (shell scripts, data files, config files) have it, and that some people may be relying on these lines in some weak form. For instance, I will do a "what =nightly" (the "=" is a zsh-ism) to see what version of nightly I'm running. I agree that compiled objects don't really need the line, though it doesn't hurt to have them in place (except for the extra work it'll cause the Tonic team to figure out how to support them). As for %I%, I'd really like to see a better solution than this. If nothing else, the number is non-unique across workspaces (like %I% is, but more so), although a pairing of that with the short changeset hash might be interesting. The real problem with driver versioning as it stands (and Steve's proposal) is that when a driver is made up of multiple source files, modifying any one of those ostensibly changes the driver. But the "version" is kept in only one of those files. Thus the developer has to make a conscious decision to apply an "empty delta" to the file with the version string in order to bump it. That's not always done -- either deliberately or not -- and makes the version string next to useless. My preference would be to replace it with the build date and/or the changeset hash of tip when the gate was built. That's a lot of info to shove into the modinfo line, so the question that gets raised in my mind is, "what are the actual requirements from Sun's service folks and anyone else who uses modinfo output to look for a version number?" Aside from these two uses of keywords, do we care at all about the rest? My off-the-cuff answer is "no, let's ditch 'em", but we should probably do an analysis of how they're actually being used Danek _______________________________________________ tools-discuss mailing list tools-discuss@opensolaris.org
