I am happy to announce a new bugfix release of virt-viewer 4.0 (gpg), including experimental Windows installers for Win x86 MSI (gpg) and Win x64 MSI (gpg). Signatures are created with key DAF3 A6FD B26B 6291 2D0E 8E3F BE86 EBB4 1510 4FDF (4096R)
All historical releases are available from:
http://virt-manager.org/download/
Changes in this release include:
- Drop support for gtk2 builds
- Require spice-gtk >= 0.31
- Require glib2 >= 2.38
- Require gtk3 >= 3.10
- Require libvirt-glib >= 0.1.8
- Increase minimum window size fo 320×200 instead of 50×50
- Remove use of GSLice
- Don’t show usbredir button if not connected yet
- Only compute monitor mapping in full screen
- Don’t ignore usb-filter in spiec vv-file
- Port to use GtkApplication API
- Don’t leave window open after connection failure
- Validate symbols from max glib/gdk versions
- Don’t use GtkStock
- Don’t use gtk_widget-modify_{fg,bg} APIs
- Drop use of built-in eventloop in favour of libvirt-glib
- Don’t open X display while parsing command line
- Fix window title
- Use GResource for building ui files into binary
- Fix crash with invalid spice monitor mapping
- Add dialog to show file transfer progress and allow cancelling
- Remove unused nsis installer support
- Include adwaita icon theme in msi builds
- Add more menu mnemonics
- Fix support for windows consoles to allow I/O redirection
- Add support for ovirt sso-token in vv-file
- Fix crash with zooming window while not connected
- Remove custom auto drawer widget with GtkRevealer
- Add appdata file for gnome software
- Misc other bug fixes
- Refresh translations
Thanks to everyone who contributed towards this release.
Until today, libvirt has used a 3 digit version number for monthly releases off the git master branch, and a 4 digit version number for maintenance releases off stable branches. Henceforth all releases will use 3 digits, and the next release will be 2.0.0, followed by 2.1.0, 2.2.0, etc, with stable releases incrementing the last digit (2.0.1, 2.0.2, etc) instead of appending yet another digit.
For the longer explanation read on…
We have the following rules about when we increment each digit in the version number
major- no one has any clue about when we should bump this
minor- bump this when some “significant”[*] features appear
micro- bump this on each new master branch release
extra- bump this for stable branch releases
[*] for a definition of “significant” that either no one knows, or that we invent post-update to justify why we changed the digit.
Now consider the actual requirements libvirt has
- A number that increments on each release from master branches
- A number that can be further incremented for stable branch releases without clashing with future master branch releases
The micro + extra digits alone deal with our two actual requirements, so one may ask what is the point of the major + minor digits in the version number ?
In 11 years of libvirt development we’ve only bumped the major digit once, and we didn’t have any real reason why we chose to the bump the major digit, instead of continuing to bump the minor digit. It just felt like we ought to have a 1.0 release after 7+ years. Our decisions about when to bump the minor digit have not been that much less arbitrary. We just look at what features are around and randomly decide if any feel “big enough” to justify a minor digit bump.
Way back in the early days of libvirt, we had exactly this kind of mess when deciding when to actually make releases. Sometimes we’d release after a month, sometimes after 3 months, completely arbitrarily based on whether the accumulated changes felt “big enough” to justify a release. Feature based release schedules are insanity as no one can predict when the next one might happen. Fortunately we wised up pretty quickly and adopted a time base release schedule where we release monthly approximately on the 1st. The only exception is over xmas/new year period, where we avoid Jan 1st and Feb 1st releases and instead have a Jan 15th release, giving a 6 week gap. There is no stated semantic difference between any of our releases off git master branch – they just include whatever happens to be ready at the time.
Considering version numbers again, it is clear that the reason why a feature based release timeline are a bad idea, is just as applicable to feature based version numbering rules. So we have decided to switch to a time based rule for incrementing the version number. Note, that this is *not* to be confused with switching to a time based version number. We want individual digits in the version number to be completely devoid of any semantics. Just as we don’t want version number changes to imply a particular level of feature changes, we also don’t want version numbers to correspond to dates of releases. IOW, we are *not* using the year and month to form the version number, rather that we are using the change in year and change in month as a trigger to update the version number. So our new version number rules are
major- bumped for the first release of each year
minor- bumped for every major release
micro- bumped for every stable branch release
Rather than wait until January 2017 to put this new rule into effect, we are pretending that July is January, so the next libvirt release will bump the major version number to 2.0.0. There after the releases will be 2.1.0, 2.2.0, etc until January 2017, when we’ll go to 3.0.0. The maintenance releases based off 2.0.0 will be 2.0.1, 2.0.2, 2.0.3, etc, and live on a v2.0-maint branch in git.
So henceforth you should not interpret the libvirt version numbers as having any semantic meaning. They are merely indicating the progression of releases.
As a reminder, libvirt promises API and ABI stability forever, and the ELF library soname version number is thus fixed forever at libvirt.so.0, regardless of what version number a release has.