First off, if I do this correctly it shouldn't affect anything
or anyone's workflow.  Here's hoping anyway :-)


We've got a lot of changes going into nbdkit.  I think we've had 53
commits since the previous release (1.1.28).  There's:

  (a) a danger we might break something without noticing and push that
  brokenness into a released tarball, and

  (b) we are planning to ship nbdkit in RHEL and would prefer a stable
  base for that.

Solution: stable and development branches

So what I'm proposing to do is to introduce stable and development
branches.  As with old Linux and libguestfs, odd minor numbers will
mean development, even minor numbers will be stable.

I will branch 1.2.0 (stable) at tag v1.1.28.  I will also make an
immediate development release (1.3.0) at current HEAD (9ac1eac).

Later I'll see if there are any simple fixes that can be backported
to make a 1.2.1 (stable) release.

Note: this does NOT mean we're planning to break the C plugin ABI.

Downstream packaging

I will add 1.3.0 to Fedora Rawhide and 1.2.0 to Fedora <= 28.
Currently Fedora <= 28 has 1.1.28, so this means only the
version number will change.

For EPEL 7, I will add 1.2.0 (currently 1.1.26) so this is a small

For RHEL 7, it would be nice to also move to 1.2.0 (currently 1.1.26)
but I'll need to discuss that with others.


Richard Jones, Virtualization Group, Red Hat
Read my programming and virtualization blog:
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.

Libguestfs mailing list

Reply via email to