On 1 Apr 2009 at 10:41, Andreas Ericsson wrote: > Ulrich Windl wrote: > > On 30 Mar 2009 at 11:06, Andreas Ericsson wrote: > > > > [...] > >> 3 It's far better to set the version number in the release-process. Usually > >> this can be done automatically by one invocation of "git describe", just > >> as git.git does it. > > > > However if you put a version number into every file and THEN commit, it's somewhat > > ridiculous (I'll have to learn about "git describe"). But for configuration > > management you want to have exactly that (find exactly the file that was shipped > > (or used to build)). > > > >> We've adopted "3" full out at $dayjob. Our build-machinery gets the version > >> number from the git tag (releases can only be built from signed tags), and > >> it updates macros and whatnot used for informing the user which version he > >> or she is running. This makes a lot more sense both from a bug-reporting > >> and from a release process view than having generated version-numbers in > > > > So your "release commits" are outside GIT? (see above) > > > > They aren't release commits. Just a script that creates a tarball and an RPM > (in our case). OK, that's what I did with CVS also, but with "CVS diff" I see the revision numbers (old and new) for every single file in a patch, while Git just uses "a" and "b". There I'd still prefer what CVS does. > > >> files. On a side-note; When I told my co-workers I'd like us to switch to > >> git, two of them asked about autoversioning features. I said there weren't > >> any and asked them to name a single time when we've actually used them for > >> anything *at all*. In a team of eight, having been programming for three > >> years with 12 releases and about 800 bugreports + feature-requests, noone > >> could mention a single time when the autogenerated version numbers had > >> actually been used for anything. > > > > Hmm: Were they visible to customers? > > > > Ofcourse they were, but they were rather useless even there, as a customer > could upgrade and the $Id$ tag still wouldn't get updated. It caused a lot > of confusion for our not-so-techsavvy users and customers. What I don't understand here is: Why wouldn't the $Id$ be updated upon upgrade? Because it's a manual process? [...] Regards, Ulrich -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
