On Thu, Jun 01, 2017 at 01:13:05PM +0200, Andrea Bolognani wrote:
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.
This is really a bug in the RPM spec file used to build from pre-released code. The recommended Fedora RPM practice for version numbers in packages from GIT snapshots, is that the release field start with a "0", and have a date stamp (and possibly git short hash) appended. The first RPM following the formal release would have a release starting with a "1". This way, every build from git you do is always newer, and the final release RPM is newer still.
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! :)
This is not that attractive from POV the language bindings. eg in the Go code, I need to make usage of the new APIs conditional at compile time. For example for the new APIs added in 3.4.0 I have code like func (v *Stream) RecvFlags(p []byte, flags StreamRecvFlagsValues) (int, error) { if C.LIBVIR_VERSION_NUMBER < 3004000 { return 0, GetNotImplementedError("virStreamRecvFlags") } n := C.virStreamRecvFlagsCompat(v.ptr, (*C.char)(unsafe.Pointer(&p[0])), C.size_t(len(p)), C.uint(flags)) ...snip... } and int virStreamRecvFlagsCompat(virStreamPtr st, char *data, size_t nbytes, unsigned int flags) { #if LIBVIR_VERSION_NUMBER < 3004000 assert(0); // Caller should have checked version #else return virStreamRecvFlags(st, data, nbytes, flags); #endif } The suggested versioning scheme would require changing all these version numbers checks to 3003090 is rather unpleasant IMHO. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|