Our current practice when it comes to bumping the version
number for libvirt is to do so immediately after a release,
eg. right after 3.4.0 is released later today someone will
push a commit that changes configure.ac to use 3.5.0 instead.
As a consequence, builds made from master will always carry
the release number of the *upcoming* release, so from a
versioning point of view there is no way to tell eg. 3.4.0-rc2
or even the final 3.4.0 release apart from a random build made
at a random time from master during 3.4.0's development cycle.
In particular, when creating RPMs from a git clone, you'll end
up having to use either 'dnf install' or 'dnf reinstall'
depending on whether or not you already installed any build
during the current development cycle.
I suggest we change our habits slightly:
* right after X.Y.0 has been released, bump the version
number to X.Y.90;
* bump the version number to X.Y.91 for rc1, X.Y.92 for
rc2 and so on;
* only bump the version number to X.Y+1.0 as the release is
being prepared, then go back to the first step and move
on with development.
This would make sure each step in the development cycle gets
its own version number, and as a pleasant side effect you'll
always be able to install newer builds using 'dnf install'.
Comments welcome! :)
--
Andrea Bolognani / Red Hat / Virtualization