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 Answers
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.h
trick for "official builds" and "overnight builds" and make the defaultversion.h
that developers use have a hard-coded string to the effect of "build from main codeline but not official - do not deploy".
With Git 2.27 (Q2 2020), "git p4" does a better job with RCS.
See commit 1ec4a0a, commit 38ecf75, commit cd1e0dc (14 Feb 2020), and commit 4935c45, commit aa8b766, commit 9f59ca4, commit 6b602a2 (11 Feb 2020) by Ben Keene (seraphire
).
(Merged by Junio C Hamano -- gitster
-- in commit 5f2ec21, 22 Apr 2020)
git-p4
: add RCS keyword status messageSigned-off-by: Ben Keene
During the p4 submit process,
git-p4
will attempt to apply a patch to the files found in the p4 workspace.
However, if P4 uses RCS keyword expansion, this patch may fail.When the patch fails, the user is alerted to the failure and that
git-p4
will attempt to clear the expanded text from the files and re-apply the patch.
The current version of git-p4 does not tell the user the result of the re-apply attempt after the RCS expansion has been removed which can be confusing.Add a new print statement after the git patch has been successfully applied when the RCS keywords have been cleansed.

- 1,262,500
- 529
- 4,410
- 5,250
-
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 Jan 26 '10 at 08:20
-
@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 Jan 26 '10 at 11:25
-
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 Jan 28 '10 at 03:46
-
@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 Jan 28 '10 at 05:02