I want to have auto-generated version number in format of 'x.x.x' or something similar to 'git tag' in Perforce. Any ideas?
+1
A:
I was not aware git tag could produce automatically a version number.
You may allude to git describe
RCS can be a way to store, and then display the version, not to generate one.
Version number schemes are many (p4 uses its own), plus labels need to be cleaned up once in a while.
You will need some kind of script to generate one (the followinf comes from the p4 mailing list):
For the dweeb who insists that "every last change requires a new version stamp" I'd suggest the following: [Warning: this is Perforce-centric.]
- Your makefile could generate version.h by running a script that does something like this:
CHANGENUM=`p4 changes -m1 -s submitted //depot/main/...#have | cut -f2 -d' '`
echo "#define VERSION \"main codeline to change #$CHANGENUM\" " > $SRC/include/version.h
2 . Then you do a build and the version string (for anything that references
VERSION) is automatically correct.
Of course, I'd do thisversion.htrick for "official builds" and "overnight builds" and make the defaultversion.hthat developers use have a hard-coded string to the effect of "build from main codeline but not official - do not deploy".
VonC
2010-01-26 07:20:28
Thanks, VonC. What I am dealing with is not a C/C++ project, it's just a bunch of documents(I'll tar them with version number periodically). But I guess the basic idea is the same. I am going to create a VERSION file and use your script to update it. I just get another two questions: 1. Where should I put this VERSION file? If I update VERSION file, I guess the CHANGENUM changes again; 2. In this way, I get no guarantee to trigger this script to update VERSION file automatically, right? (There are couple of guys who can reach and change the contents of this folder)
aXqd
2010-01-26 08:20:54
@aXqd: the idea is indeed the same, for any language. The usual place for such a file is the root directory, but any other place *defined by convention* in your project will do. The trigger is not guaranteed to *always* run this way, so some kind of change-content trigger may be better here.
VonC
2010-01-26 11:25:02
Sorry, English is not my mother tongue. What I wanted to ask by my 1st question is that 'After I do a submit, I will trigger a script to update the VERSION file, but then I have to submit that new VERSION file again, so the CHANGENUM will also change again'. It seems to be a loop here.
aXqd
2010-01-28 03:46:18
@aXqd: usually, that kind of trigger is able to detect a submit of just one file (the `VERSION` one)... and will not do anything in *that* case.
VonC
2010-01-28 05:02:04