We'd like to offer a comment from the Xen Project to this story for background on our process and thinking here. 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 22.214.171.124 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 126.96.36.199 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 188.8.131.52 not being widely used.
Because we documented the missing patches in the release notes and release announcement, nobody who downloads the signed source tarballs from our official download page should be unaware of the missing security patches. In addition, the tarballs from our official download pages are primarily consumed by Linux distros, which will apply the missing patches and any additional security fixes that turn up between Xen 4.6.1 and their own release. Most of our users consume binaries from those distros. The other group of users which consume the tarballs are power users, which are used to applying security patches.
This leaves the question, why 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, well 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.
There has been some confusion about Xen Project and our security processes because we do things differently than a lot of other projects out there. We handle and document every single security bug that is raised with the project to ensure that even low-severity bugs are fixed and known. Many projects and commercial software products do not do this and only handle bugs with severe security implications in recommended configurations, rather than handling even minor bugs in non-recommended configurations like we do. Essentially, we do go through this process as it makes everyone more secure and provides more control to those that use Xen.