libvirt/docs/downloads.rst

Downloads

Project modules

The libvirt project maintains a number of inter-related modules beyond the core C library/daemon.

Libvirt

Module	Releases	GIT Repo	Bug Tracker	GIT Mirrors	Resources
libvirt	libvirt	gitlab	issues	github	api ref changes

Language bindings

Module	Releases	GIT Repo	Bug Tracker	GIT Mirrors	Resources
C#		gitlab	issues	github
Go	pkg.go.dev	gitlab	issues	github	api ref
Java	libvirt	gitlab	issues	github
OCaml	libvirt	gitlab	issues	github
Perl (Sys::Virt)	cpan	gitlab	issues	github	api ref changes
PHP	libvirt	gitlab	issues	github
Python	libvirt pypi	gitlab	issues	github
Ruby	libvirt	gitlab	issues	github
Rust	crates.io	gitlab	issues	github	api ref

Integration modules

Module	Releases	GIT Repo	Bug Tracker	GIT Mirrors	Resources
GLib / GConfig / GObject	libvirt	gitlab	issues	github
Go XML	pkg.go.dev	gitlab	issues	github	api ref
D-Bus	libvirt	gitlab	issues	github
Console Proxy		gitlab	issues	github
CIM provider	libvirt	gitlab	issues	github
CIM utils	libvirt	gitlab	issues	github
SNMP	libvirt	gitlab	issues	github
Application Sandbox	libvirt	gitlab	issues	github

Testing

Module	Releases	GIT Repo	Bug Tracker	GIT Mirrors
TCK	libvirt	gitlab	issues	github
Test API		gitlab	issues	github
Continuous Integration Config		gitlab	issues	github
CIM Test		gitlab	issues	github

Documentation

Module	GIT Repo	Bug Tracker	GIT Mirrors
Publican Brand	gitlab	issues	github
App Development Guide	gitlab	issues	github
App Development Guide Python	gitlab	issues	github
virsh Command Reference	gitlab	issues	github

Primary download site

Most modules have releases made available for download on the project site via HTTPS. Some modules are instead made available at alternative locations, for example, the Perl binding is made available only on CPAN.

• libvirt.org HTTPS server

Primary release schedule

The core libvirt module follows a time based plan, with releases made once a month on the 1st of each month give or take a few days. The only exception is at the start of the year where there are two 6 weeks gaps (first release in the middle of Jan, then skip the Feb release), giving a total of 11 releases a year. The Python and Perl modules will aim to release at the same time as the core libvirt module. Other modules have independent ad-hoc releases with no fixed time schedule.

Release numbering

Since libvirt 2.0.0, a time based version numbering rule is applied to the core library releases. As such, the changes in version number have do not have any implications with respect to the scope of features or bugfixes included, the stability of the code, or the API / ABI compatibility (libvirt API / ABI is guaranteed stable forever). The rules applied for changing the libvirt version number are:

major

incremented by 1 for the first release of the year (the Jan 15th release)

minor

reset to 0 with every major increment, otherwise incremented by 1 for each monthly release from git master

micro

always 0 for releases from git master, incremented by 1 for each stable maintenance release

Prior to 2.0.0, the major/minor numbers were incremented fairly arbitrarily, and maintenance releases appended a fourth digit. The language bindings will aim to use the same version number as the most recent core library API they support. The other modules have their own distinct release numbering sequence, though they generally aim to follow the above rules for incrementing major/minor/micro digits.

Maintenance releases

In the git repository are several stable maintenance branches for the core library, matching the pattern vmajor.minor-maint; these branches are forked off the corresponding vmajor.minor.0 formal release, and may have further releases of the form vmajor.minor.micro. These maintenance branches should only contain bug fixes, and no new features, backported from the master branch, and are supported as long as at least one downstream distribution expresses interest in a given branch. These maintenance branches are considered during CVE analysis. In contrast to the primary releases which are made once a month, there is no formal schedule for the maintenance releases, which are made whenever there is a need to make available key bugfixes to downstream consumers. The language bindings and other modules generally do not provide stable branch releases.

For more details about contents of maintenance releases, see the wiki page.

GIT source repository

All modules maintained by the libvirt project have their primary source available in the libvirt group on GitLab. Each module can be cloned anonymously using:

git clone https://gitlab.com/libvirt/[module name].git

In addition to this primary repository, there are mirrored read-only git repositories on GitHub:

https://github.com/libvirt/

And there are also read-only mirrors on libvirt.org:

git clone https://libvirt.org/git/[module name].git

Note that for most repositories, development happens via merge requests on GitLab. However, for the main libvirt.git repository all patch review and discussion only occurs on the libvir-list mailing list.

The GitHub repository is read-only and pull requests and issues there are ignored.

Signing keys

Source RPM packages and tarballs for libvirt and libvirt-python published on this project site are signed with a GPG signature. You should always verify the package signature before using the source to compile binary packages. The following key is currently used to generate the GPG signatures:

pub  4096R/10084C9C 2020-07-20 Jiří Denemark <jdenemar@redhat.com>
Fingerprint=453B 6531 0595 5628 5547  1199 CA68 BE80 1008 4C9C

It can be downloaded from this site or from public GPG key servers.

Releases prior to libvirt-6.6 were signed with the following GPG key:

pub   dsa1024 2000-05-31 [SC]
C744 15BA 7C9C 7F78 F02E  1DC3 4606 B8A5 DE95 BC1F
uid           [ unknown] Daniel Veillard (Red Hat work email) <veillard@redhat.com>
uid           [ unknown] Daniel Veillard <Daniel.Veillard@w3.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Starting from libvirt-6.6.0 the upstream releases will be done by Jiří Denemark
signed with his PGP key:

pub  4096R/10084C9C 2020-07-20 Jiří Denemark <jdenemar@redhat.com>
Fingerprint=453B 6531 0595 5628 5547  1199 CA68 BE80 1008 4C9C

This message is signed by the old signing key which was used for previous
releases.
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEE20ZoG7ka3OoXD6LUFViLJllr6l0FAl/8H9cACgkQFViLJllr
6l3iVwgAm9n703/QoIfPbxT5qGQzWK6LNriEcG2R9MLgFcW+UuGA9cqIBLhH1RaJ
q7Gc3gK0dgE2HAF6DxuG5+nkDY6LdmonLOVFWQkMCh41JHFrV6tw8y9hc/RNOb/m
gFAl4HpwYisjTRvsTRcpR3ElK6lI0Yu4GY4gJxj5qH4L5exR+kkylwuAxqP+wuyY
b/L/tP76F4+Q9SSPj0M01NRVC7V8m3yvnok5y374vtxvRFome0WMELn81vphxBLx
X7LQ1LyjvRs0HhN5MutJES5FYDzArTYZfZJozJgE465XrHxMMCbXbZ/AgAs/aD+5
x+m2mFplbS57tMEoMBP/ezbbL5wpvA==
=KnaO
-----END PGP SIGNATURE-----