[libvirt] [RFC] Version numbers outside of releases

[Daniel P. Berrange]

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 :|