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

[Wei Liu <wei.liu2@xxxxxxxxxx>]

On Wed, Jun 15, 2016 at 01:38:41AM -0600, Jan Beulich wrote:
> >>> On 14.06.16 at 19:57, <ian.jackson@xxxxxxxxxxxxx> wrote:
> > 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.
> 
> As said on IRC this morning, while I continue to by unconvinced of the
> arguments, being the only one wanting to stick with 4.6.2 I'm not going
> to argue any further on this - be it 4.6.3 then. The only thing I would
> really like to ask is that this time (as should have happened in the first
> place), before tagging respective trees, everyone please make sure
> everything intended to be in the tree they're responsible for indeed is
> there. I really want to be able to rely on everybody having their trees
> (or parts thereof) under control.
> 
> (I don't, btw, think that mini-os strictly needs re-tagging. We've
> shipped 4.6.1 without a new tag too, since there were no changes.
> But of course if a new tag is going to be made, please make sure
> you let me know of its existence, so my final Config.mk adjustment
> can be done appropriately.)
> 

I would like to tag 4.6.3 to avoid causing confusion.

Let me know when the decision about version number is final.

Wei.

> Thanks, Jan
> 

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