Menu
I would be interested to in knowing how you out there handle the bumping the version number for new releases issue.
How do you handle the version number in associated files like man pages, etc.
The software is build with the gnu tool chain so autoconf, automake, etc are available and used for the version number of the application. So that information can be reused.
git is used as a vcs.
One possibility would be introduce an extra, new target in Makefile.am that does a sed/awk to replace version number and dates in all associated files. That target could be called once at the beginning (right after branching) of the development of a new release.
Then the project could build with the correct information when people would do a git clone of the project or when a release tarball is done. Of course one has to remember to run this make target when starting development of a new release.
Another option would be to do the sed/awk replacement with a hook for the dist target.But this would put the git repository of the project in a state were no correct version number is associated with the associated files.
I prefer doing the first solution as it also records the correct version number inside the git history.
When doing a sed/awk replacement do you prefer doing it "in-file" or with a template in-file liek the autoconf/automake tools do. I see both advantages and disadvantages in both methods.
How do you handle versioning of associated files. Do you change them at the beginning of the development phase, do you change them when just before shipping, do you do infile replacement or do you prefer using a template?
THX.
538
A normal version number MUST take the form X.Y.Z where X, Y, and Z are non-negative integers, and MUST NOT contain leading zeroes. X is the major version, Y is the minor version, and Z is the patch version. Each element MUST increase numerically. For instance: 1.9.0 -> 1.10.0 -> 1.11.0.
Numbering each version helps to distinguish one version from another. It may be suitable, simply to number each version, regardless of the changes, using consecutive whole numbers e.g. V 1.0; V 2.0; V 3.0 etc. to track which version of the document is being worked on.
First Number: Tracks major changes. Second Number: Tracks minor changes. Third Number: Tracks patches or mere bug fixes. Fourth Number: Tracks changes less significant than a patch.
A common solution nowadays is to invoke AC_INIT with an m4_esyscmd argument to generate the VERSION from git. For example, autoconf's configure.ac contains the lines:
AC_INIT([GNU Autoconf],
m4_esyscmd([build-aux/git-version-gen .tarball-version]),
[[email protected]])
where build-aux/git-version-gen is a simple script that calls 'git describe' to generate the version number. (see gnulib)
There are drawbacks to this approach, but it can be effective.
101
I think that the standard way to do this is to use Git's hook system and m4 or sed/awk to do the search/replace as you suggest. You just need a special token with in a comment in each file (probably in the header).
Here's the reference on githooks and here's a few pages written by people solving the same problem:
Both of these rely on storing the version number in a file somewhere in your source tree.
I also came across a took called 0release that claims to automate release creation (and setting version numbers).
Finally, regarding release numbers, this is addressed in several other questions:
28
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
