[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-devel] Next 4.6.x stable release, numbering, qemu-tag



We still have an unanswered question about the forthcoming 4.6.x
stable release.  To summarise:

After tagging qemu-xen-4.6.2, a build issue was discovered: qemu-xen
wanted a new patch to fix the build on recent Ubuntu.  We decided to
include this patch in the forthcoming stable point release of Xen 4.6.
So we will need to retag qemu-xen as part of the release process.

In my view the correct thing to do in this situation is to skip the
version number.  This is also, I think, quite conventional in other
projects, if new release-critical changes are discovered during the
release preparation.

I think it would be quite wrong to "release 4.6.2 with qemu-xen
c5fbb56ac828".  Indeed, I think it is now impossible to do a correct
release of 4.6.2 containing qemu-xen c5fbb56ac828, because making a
release of Xen (including a stable point release) involves making a
corresponding tag in the qemu trees.

Those corresponding tags are not just a technical link to Config.mk,
used by build automation.  They also have an independent existence.
They are PGP signed.  They can be verified outside the context of
xen.git's Config.mk.  They are looked at by humans.  git-describe uses
them.  Xen-specific automation might pick them up, knowing our tag
naming conventions.

We should therefore discard the version number 4.6.2 and proceed with
the forthcoming point release as 4.6.3.  Integers are plentiful and it
does not matter if we waste one, particularly in the point release
number.  We can mention briefly somewhere (release notes maybe) that
we skipped 4.6.2 because we discovered a patch we wanted to include,
while we were in the process of preparing the release.

We have spoken about this informally and it seems that Jan, the
primary stable tree maintainer, does not agree (or at least, has not
yet been convinced).

This may seem like a bikeshed issue to some.  But, I'm afraid that I
am very reluctant to do as Jan proposes, and proceed with a 4.6.2
release referring to a qemu tag such as qemu-xen-4.6.2.1 or 4.6.2b or
something.  Before doing that I would feel the need to escalate this
question to the Xen Project Committers (CC'd).

And, we ought not to let this issue delay the actual point release and
it is close to being on the critical path.  A decision is needed.

Thanks for your attention.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.