qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gordon Sim <g...@redhat.com>
Subject Re: 0.30 release update - alpha is available
Date Fri, 08 Aug 2014 10:33:54 GMT
On 08/08/2014 10:46 AM, Robbie Gemmell wrote:
> I am in favour of having targeted source release archives, each with the
> own votes and tags.
>
> I would have preferred to reorganise the tree a bit first before beginning
> this, so that what goes in each archive is better reflected in the layout
> (again something I was planning to bring after 0.30 went out), but the main
> benefit would come from actually deciding what individual things we will
> release.

I'd suggest we take the separate source bundles from the previous 
release as a starting point.

We would need to add a specific java source bundle to that list. Would 
there be one bundle or would e.g. the 1.0 JMS client be in its own 
source bundle?

There may be other things we can consider adding if they don't require 
much work to get them ready. (E.g. if possible I'd quite like to see the 
qpid-python-tests released, but it certainly is not a blocking issue for 
0.30).

We should also remove anything we think is either unlikely to get the 
requisite votes or has not changed significantly. I'd suggest that would 
include the qpid-wcf zip.

So something like:

qpid-cpp-0.30.tar.gz
qpid-python-0.30.tar.gz
qpid-qmf-0.30.tar.gz
qpid-tools-0.30.tar.gz
+ whatever we need for java
+ anything else

In terms of process we could proceed through beta as before to the first 
release candidate considered ready for voting. The vote would then 
actually be a set of votes on (for arguments sake) each specific bundle 
above. Each would require three binding +1s to be released.

If any artefact doesn't get sufficient votes, but has no explicit issues 
identified with it preventing a vote, it would get dropped. Hopefully 
this won't happen if we choose the release artefacts up front, but its 
there as a backstop anyway.

If we have sufficient testing prior to calling the vote we should be 
able to avoid having blocking issues raised in the vote itself. However 
if this were to occur we would then have two options open.

In the first we would cancel all votes and discard all artefacts, make 
the changes to the release branch then produce a complete new set of 
artefacts and restart the vote on each.

Alternatively, we could tag the revision from which those artefacts that 
passed their votes were generated, and only produce new candidates of 
those in which issues were identified. This would obviously be less work 
for the testers, so if feasible from the release managers point of view 
would be my preference.

I think we would want to have a time limit in which all artefacts were 
ready for their 0.30 release, or else dropped (this is something that 
could be relaxed for subsequent releases). When we have the final set of 
voted artefacts we can announce the release and push them up to the 
appropriate location.

Does this sound feasible/agreeable?

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org


Mime
View raw message