Currently in my practice I use VERSION file to store:
major=2 minor=0 fix=1
which mean that sources for product version v2.0.1 or newer.
Before each release I must commit update to this file so tag with name tag2.0.1 or release-2.0.1 cover above content (and not previous version!).
I think that it is possible to avoid this job by automatically generating VERSION file from build script.
Look to rev history:
+--+-----+----------------------+-YY--+----+------+------+-HH-->
dev| | ^ ^ | | | | |
| | | | | | v v v
| | | | | | +--+------+-ZZ---+-->
| | | | | | b2 | | |
| | | | | | v v v
| | | | | | t2.0.0 t2.0.1 t2.1.0
v v | | v v
t0.1.0 +---+--XX--+-+---+-+-----+------+------+------+------+--->
b1 | | | | | | | |
v v v v v v v v
t1.0.0 t1.0.1 t1.0.2 t1.1.0 t1.2.0 t1.2.1 t1.2.2 t1.2.3
At point XX version is 1.0.0, at point YY version is 1.0.2, at point ZZ version is 2.0.1.
For point HH is don't know how set version. I think it must be 1.0.2, because we does not merge dev branch with release branch b2.
I read:
$ hg help revsets
but don't see how can I find nearest tag to given revision. With Git and Bzr I have less experience...
Or if this s not possible I look for arguments. Also I like to hear how avoid manually maintain VERSION file if this possible (or arguments why this is not possible).
PS. VERSION file needed to maintain package dependency and to identify product source state in feedback from users.
PSS. nearest tag to given revision term can look something fuzzy but every developer can say on which version of product it works. Why this can not do machine?
You could use something like this:
hg log --template "{latesttag}-{latesttagdistance}-{node|short}\n" --rev <REV>
Which returns a string like:
2.1.4-2-12eeab7a8073
This tells us that:
Read about templates for more information.
Git has a built-in describe command that provides the same information. However, you must understand that by default it only works with annotated tags (see the man page for details).