First off, if I do this correctly it shouldn't affect anything or anyone's workflow. Here's hoping anyway :-) Problem ------- 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 update. 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. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://people.redhat.com/~rjones/virt-top