Xen Project 4.6.1 Maintenance Release is Available

I am pleased to announce the release of Xen 4.6.1. Xen Project Maintenance releases are released in line with our Maintenance Release Policy: this means we make one new point release per stable series every 4 months, which include back-ports of bug-fixes and security issues.
I am pleased to announce the release of Xen 4.6.1. This is available immediately from its git repository
http://xenbits.xen.org/gitweb/?p=xen.git;a=shortlog;h=refs/heads/stable-4.6
(tag RELEASE-4.6.1)
or from the XenProject download page
http://www.xenproject.org/downloads/xen-archives/xen-46-series/xen-461.html
(where a list of changes can also be found).
Note that, as also mentioned on the web page above, due to two oversights the fixes for both XSA-155 and XSA-162 have only been partially applied to this release. (Note further that the same applies to the recently announced 4.4.4 release.)
We recommend all users of the 4.6 stable series to update to this first point release.
Additional note published Feb 17th: We detected the missing patches before the official release, but towards the end of the release process. We then had a discussion whether to make a new release which would have forced us to skip a release number (aka move from 4.6.0 to 4.6.1.1 or 4.6.2) or release 4.6.1 with two security patches which were incomplete, and document what is missing. At this point, we had to decide whether to re-tag (and thus re-number the release) or whether to document any issues. A similar issue happened in 2013, when we released Xen 4.1.6.1 instead of Xen 4.1.6. At that time it became clear that many consumers of Xen have difficulties with a version number that does not fit into the normal version numbering pattern, which led to Xen 4.1.6.1 not being widely used. We cannot re-spin a release without changing the version number if issues are discovered late during the release process. Firstly, making a release involves both extensive testing and also has a security dimension. Normally, after testing succeeds we create a signed tag in the git tree. This means that there is a secure way of accounting for where the tarball came from. We then rebuild and do additional testing, write the release notes, do some more checking and sign the tarballs. The missing patches were discovered on Thursday, before the official release on Monday, but after we created the signed tag. Signed tags cannot be removed, as they have to be tamper proof, which makes everyone more secure.